بازگشت تا زمانی که روحیه بهبود یابد ادامه خواهد داشت

بسیاری از خوانندگان آگاه خواهند بود که پس از شروع دوره بتا، تعداد غیرعادی بالایی از ویژگی ها از شاخه PostgreSQL 19 بازگردانده شده است. داشتن برخی برگشت‌ها غیرعادی نیست، شاید بتوان انتظار داشت که در هر چرخه یک مورد بازگردد. اما این بار، حدود 8 تا 10 ویژگی مهم، بسته به نحوه شمارش، برگردانده شده اند، و برخی از آنها کاملا در اواخر دوره بتا. من به‌عنوان توسعه‌دهنده یا ارائه‌دهنده برخی از آن ویژگی‌ها، برخی از آن‌ها را دریافت کرده‌ام، و سؤالاتی در مورد آن دریافت کرده‌ام، بنابراین می‌خواهم لحظه‌ای در مورد آن فکر کنم.

سعی می‌کنم کمی به کارهای مشابهی که به طور فعال در آن شرکت نداشتم تعمیم دهم، اما اینها فقط نظرات من در این مرحله است.

فکر نمی‌کنم ما، یعنی همه توسعه‌دهندگانی که تحت تأثیر قرار گرفته‌اند، زمان کافی برای تأمل کامل در مورد همه این‌ها داشته باشیم. اما در اینجا چند فکر وجود دارد. احتمالا ترکیبی از اینها و ترکیبی متفاوت در مورد هر ویژگی برگردانده شده است.

شاید ما به اندازه کافی خوب کار نکردیم. شاید کد به اندازه کافی خوب نبود. یاد خواهیم گرفت و پیشرفت خواهیم کرد. این احتمالا بخشی از آن است، و من در اینجا به آن اشاره می‌کنم تا این تصور را ایجاد نکنم که فقط عوامل دیگری هستند که قرار است به آن اشاره کنم.

همچنین می تواند یک تصادف باشد. شاید ما آنقدر خوب بوده‌ایم که سعی کرده‌ایم با چندین ویژگی مقابله کنیم که خیلی سخت بودند، یا حداقل خیلی سخت به پایان رسید.

برخی از ویژگی‌های بازگردانده شده دارای نقص‌های معماری قابل توجهی بودند که رفع آن‌ها به سرعت و در طول بتا دشوار بود. اما یک دنباله طولانی از مسائل نسبتا بی ضرر نیز وجود داشت که شامل موارد مختلف لبه بود. در زمان های گذشته، بسیاری از این موارد تا مدت ها بعد ظاهر نمی شدند و ما آنها را ذره ذره در طول پنج سال بعدی اصلاح می کردیم. اما با بررسی کد به کمک LLM، این نوع چیزها می‌توانند خیلی سریع‌تر پیدا شوند و سپس به فهرستی از چهل گزارش نقص خیره می‌شوید.

و حتی اگر هر یک از آنها به طور متوسط ​​فقط نیاز به یک تعمیر سه خطی داشته باشد، هزینه سربار ثابتی برای رسیدگی به هر یک از آنها وجود دارد و سپس زمان شما تمام می شود. بسیاری از ویژگی‌های برگردانده شده تحت تأثیر مدت‌ها پیش نوشته شده‌اند، زمانی که بررسی کد به کمک LLM به اندازه حال حاضر مفید نبود، به این معنی که نوار کیفیت مؤثر پس از زمان نوشتن و تعهد این ویژگی افزایش یافته است. مگر اینکه قابلیت‌های بازنگری کد به کمک LLM با سرعت فعلی بهبود یابد، این وضعیت باید برای چرخه‌های توسعه آینده مرتب شود.

نتیجه آن این است که، حداقل در بیشتر موارد، تا آنجا که من می توانم بگویم، این وضعیت به دلیل «کدگذاری vibe» نیست. این کد قبل از اینکه یک امکان وجود داشته باشد نوشته شده بود.

به دلیل Vulnpocalypse، بسیاری از توسعه دهندگان ارشد بین، مثلا آوریل (آغاز توقف ویژگی برای PostgreSQL 19، و همچنین شروع Vulnpocalypse) و آگوست (جدیدترین نسخه امنیتی PostgreSQL) مشغول کار بر روی رفع مشکلات امنیتی بودند. به همین دلیل، بررسی و آزمایش اضافی معمولی که در طول دوره بتا انجام می‌شود کاهش یافت و سپس دوباره در ماه اوت انجام شد. احتمالا به همین دلیل است که بسیاری از مسائل جدید در اواخر دوره بتا کشف شدند و به همین دلیل است که بسیاری از بازگردانی‌ها اینقدر دیر اتفاق افتادند، و این همان چیزی است که همه این موارد را بسیار قابل توجه کرده است.

باز هم، برخی از مسائل اساسی‌تر بودند، اما دنباله طولانی‌تری از مسائل کوچک‌تر نیز وجود داشت، و من احساس می‌کنم که با زمان بیشتر، مثلا دو ماه، می‌توان به آن‌ها رسیدگی کرد (با توجه به تمرکز کافی، اما توجه داشته باشید که Vulnpocalypse در حال انجام است). اما جامعه به جای تأخیر در دریافت اصلاحات بیشتر، تلاش برای پایبندی به زمان‌بندی انتشار را ترجیح داد.

پیچیدگی سیستم باعث شده است که برخی از ویژگی ها به شدت پیچیده شوند و به اندازه کافی داربست برای پشتیبانی از آن در کد وجود ندارد. به عنوان یک مثال انتزاعی، برخی از ویژگی های زبان پرس و جو در سطح SQL را در نظر بگیرید. آیا با دامنه ها کار می کند؟ در مورد دامنه های روی یک نوع ترکیبی چطور؟ جایی که یکی از فیلدها هم دامنه است؟ و دامنه دارای محدودیت نه صفر است؟ و یکی از ستون ها حذف شد و دوباره اضافه شد؟ و این بخشی از یک پارتیشن جدول است که با ترتیب ستون های متفاوت جدا شده و دوباره وصل شده است؟ و این بخشی از یک نمای است که از یک secur فراخوانی می شود

تابع ity-definer از یک ماشه؟ و غیره. هیچ کس نمی تواند این موارد را به صورت دستی آزمایش کند یا حتی این موارد آزمایشی را برشمرد. اما fuzzing به کمک LLM می تواند مشکلات را در این مورد خیلی سریع پیدا کند. بنابراین این احتمالا باید بخشی از توسعه ویژگی در آینده باشد. اما ما همچنین باید در مورد قوی‌تر کردن رابط‌های داخلی فکر کنیم تا هر ترکیب متفاوتی از زمینه‌ها فرصت‌های زیادی از تعاملات را ایجاد نکند.

من دوست دارم در PostgreSQL بگویم "همه چیز با همه چیز کار می کند". این بخشی از جذابیت است که می توانید مواردی مانند این بسازید و انتظار داشته باشید که کار کنند. من اصلا نمی خواهم از آن دست بکشم. اما جریمه قابل توجهی را برای توسعه ویژگی اعمال می کند که همه باید از آن آگاه باشند.

به عنوان آخرین نکته، جامعه توسعه PostgreSQL مدتی است که امکان ارتکاب ویژگی ها با نوعی وضعیت "تجربی" و سپس بلوغ آنها را در درخت اصلی در نظر گرفته است. این نیز یکی از احتمالات برای پرداختن به نکته قبلی خواهد بود. این یک ابزار مفید برای حداقل برخی از ویژگی‌های بازگردانده شده بود، اما ما هنوز راهی برای انجام این کار پیدا نکرده‌ایم، و برخی از کارها دچار سوء تفاهمات مرتبط با این موضوع شدند. این یک نکته مشخص برای کار است.

اول از همه، از دیدگاه شخصی من، از همه کسانی که به صورت حضوری یا آنلاین برای ابراز حمایت و تشویق تماس گرفته اند، تشکر می کنم. این مهمترین چیز است. من مطمئن هستم که بسیاری از ویژگی‌های بازگردانده شده قبل از مدت طولانی بازخواهند گشت.

PostgreSQL 19 همچنان یک نسخه عالی خواهد بود. REPACK به طور همزمان، تکرار منطقی توالی ها (که خود یک ویژگی قبلا برگردانده شده است)، و اشاره برنامه ریز با pg_plan_advice، فقط برای انتخاب چند عنوان سرفصل، این نسخه را بسیار جذاب می کند. و پس از همه بررسی های بیشتر، بسیار قوی خواهد بود.

اکنون پیش بینی چیزها دشوار است. چند ماه پیش گفتم، PostgreSQL 20 ممکن است هیچ ویژگی جدیدی نداشته باشد، فقط رفع اشکال داشته باشد. معلوم شد که کارها حتی سریع‌تر پیش رفتند، و PostgreSQL 19 اکنون، به نوعی، دارای نصف ویژگی‌های اصلی است که در آن زمان انتظار می‌رفت، اما اکنون ما چند ویژگی خوب 80٪ آماده داریم که برای PostgreSQL 20 در صف قرار گرفته‌اند که فقط به 80٪ باقیمانده نیاز دارند تا انجام شوند!