موعد إطلاق PostgreSQL 19 ينتقل من مطلع أكتوبر إلى 19 نوفمبر، والإصدار 20 يتحول من إصدار إصلاحات فقط إلى وريث لما بين 8 و10 ميزات.
ضمن ملف: نماذج الذكاء الاصطناعي
بقلم: ليلى | محررة أدوات المطورين · صوت تحريري بإشراف بشري
المصدر الأساسي: The Register
لماذا يهم
الفرق التي تخطط لترقية PostgreSQL ستنتظر شهراً إضافياً وتخسر ميزات مثل SQL/PGQ حتى الإصدار 20. ومشرفو المشاريع مفتوحة المصدر صار عليهم أن يخصصوا وقتاً بشرياً لإصلاح ما تكشفه أدوات المراجعة بالذكاء الاصطناعي قبل الإطلاق.
أدوات مراجعة الشيفرة المعتمدة على LLM صارت تكتشف العيوب أسرع مما يستطيع البشر إصلاحه، وأول مشروع كبير يدفع ثمن ذلك علناً هو PostgreSQL 19. بحسب The Register، أجّلت مجموعة تطوير PostgreSQL العالمية الإطلاق العام من أواخر سبتمبر أو مطلع أكتوبر إلى قرابة 19 نوفمبر (وفقاً لـ The Register)، وسحبت ما بين 8 و10 ميزات كبيرة نُقل إطلاقها إلى PostgreSQL 20 في العام المقبل (وفقاً لـ The Register). المفارقة أن التأخير لم يسببه ضعف الشيفرة، بل قوة أدوات فحصها.
التفسير جاء من Peter Eisentraut، نائب الرئيس في EDB، وهي شركة دعم واستشارات متخصصة في PostgreSQL، وأحد أبرز المساهمين الذين يملكون صلاحية دمج الشيفرة في المشروع. بحسب تدوينة كتبها Eisentraut ونقلتها The Register، فإن بعض الميزات المسحوبة فيها عيوب معمارية جوهرية كان يصعب إصلاحها “بسرعة وخلال مرحلة beta”. هذا الجزء من القصة مألوف في أي مشروع برمجي كبير. الجزء الجديد هو ما يأتي بعده.
بحسب Eisentraut كما نقلت The Register، كشفت المراجعة بمساعدة LLM أيضاً ذيلاً طويلاً من “المشكلات غير الضارة نسبياً المتعلقة بحالات حدّية متنوعة”. في الدورات السابقة كانت هذه المشكلات تمر دون أن ينتبه لها أحد، ثم تُصلح تدريجياً عبر تحديثات تمتد غالباً على مدى خمس سنوات بعد الإطلاق (وفقاً لـ The Register). ويصف Eisentraut ما حدث هذه المرة بقوله: “مع مراجعة الشيفرة بمساعدة LLM يمكن العثور على هذه الأمور أسرع بكثير، ثم تجد نفسك أمام قائمة من أربعين تقرير عيب. حتى لو احتاج كل منها في المتوسط إلى إصلاح من ثلاثة أسطر، فهناك كلفة ثابتة للتعامل مع كل واحد، ثم ينفد منك الوقت” (وفقاً لـ The Register).
هنا تكمن قيمة القصة لأي فريق هندسي. إصلاح من ثلاثة أسطر لا يعني عملاً من ثلاثة أسطر. كل تقرير يحتاج إلى قراءة وتأكيد ونقاش واختبار ودمج، وهذه الكلفة الثابتة بشرية بالكامل. تقديرنا أن الذكاء الاصطناعي لم يرفع عدد العيوب، بل نقل لحظة اكتشافها من سنوات ما بعد الإطلاق إلى أسابيع ما قبله، وبالتالي نقل الكلفة إلى المرحلة التي يكون فيها الوقت أضيق.
بحسب The Register، لم تكن مراجعة الـLLM مفيدة بالقدر الحالي حين كُتبت التحديثات الكبرى لهذا الإصدار، ثم تحسّن فهمها وفاعليتها في الأشهر السابقة للإطلاق. يقول Eisentraut إن “معيار الجودة الفعلي ارتفع بعد كتابة الميزة ودمجها”، ويتوقع أن يستقر الوضع في دورات التطوير القادمة، بشرط ألا تواصل قدرات المراجعة تحسّنها بالوتيرة الحالية. وحرص بحسب المصدر نفسه على نفي أن يكون “vibe coding” وراء السحب، لأن هذه الطريقة لم تكن متاحة حين كُتبت معظم الميزات الجديدة. هذا الشرط في كلامه أهم من التطمين نفسه. فإذا استمر منحنى التحسّن، سيتكرر المشهد مع كل دورة، وفي كل مشروع مفتوح المصدر يعتمد على عدد محدود من المراجعين.
أبرز ما خرج من الإصدار، بحسب The Register، دعم SQL Property Graph Queries المعروف بـSQL/PGQ، وهو جزء من معيار SQL منذ 2023 (وفقاً لـ The Register). يوفّر هذا الدعم صياغة لاستكشاف العلاقات بين عُقد تربطها حواف، وقد أُزيل تطبيقه في PostgreSQL بسبب مشكلات لم تُحل. ونقلت The Register عن المساهم Tom Lane تحذيره في حينه: “أنا مستعد للمراهنة على عشاء بأننا إذا أطلقناها في v19 فستظهر بعد الإطلاق عيوب لا يمكن إصلاحها حتى v20”.
ما بقي في الإصدار ليس قليلاً. بحسب The Register، يَعِد Eisentraut بأن PostgreSQL 19 سيبقى “إصداراً رائعاً”، وأنه “سيكون متيناً جداً بعد كل هذا التدقيق الإضافي”. ومن أبرز ما يتضمنه أمر REPACK CONCURRENTLY، الذي يستعيد مساحة القرص دون اللجوء إلى عملية VACUUM FULL التي تقفل الجدول. إذا كنت تدير جداول إنتاجية كبيرة لا تحتمل التوقف، فهذه الميزة وحدها سبب كافٍ لمتابعة موعد الإطلاق. أما PostgreSQL 20، فبحسب Eisentraut كما نقلت The Register، كان المطورون يتوقعون قبل أشهر قليلة أن يقتصر على إصلاح العيوب دون ميزات جديدة، وصار الآن مرشحاً لاستقبال الميزات المؤجلة.
وزن الخبر يأتي من وزن المشروع. بحسب The Register، اقترح Michael Stonebraker قاعدة Postgres عام 1986، وفي 1994 استبدل Andrew Yu وJolly Chen لغة الاستعلام POSTQUEL بـSQL، ثم أتاحا قاعدة البيانات مجاناً وقابلة للتعديل عام 1995 بترخيص أكثر مرونة وأعادا تسميتها PostgreSQL (وفقاً لـ The Register). وتصفها The Register بأنها قاعدة البيانات الأكثر شعبية بين المطورين المحترفين، بفضل الخدمات التي بنتها عليها كبرى شركات السحابة الثلاث، وتعدد الأنظمة الموزعة المتوافقة معها على مستوى البروتوكول.
القصة تستند إلى مصدر وحيد هو The Register، الذي ينقل بدوره عن تدوينة Eisentraut، ولم يتسنَّ التحقق بشكل مستقل من القائمة الكاملة للميزات المسحوبة، كما أن موعد 19 نوفمبر تقديري ولم يُعلن بوصفه موعداً نهائياً ملزماً. ومع ذلك، الدرس واضح بما يكفي: إذا أضفت أداة مراجعة بالذكاء الاصطناعي إلى مسار عملك هذا الشهر، فهل خصصت في جدولك وقتاً لإصلاح ما ستجده؟ PostgreSQL اختار التأجيل بدل إطلاق إصدار يعرف عيوبه، ونرى أنه القرار الصحيح، لكنه أيضاً إنذار مبكر بأن جداول الإطلاق المبنية على قدرة الفحص القديمة لم تعد واقعية.
المصادر
