PostgreSQL 19: كود أقل في التطبيق وSQL أكثر

في 16 يوليو 2026 صدرت النسخة التجريبية الثانية من PostgreSQL 19، بعد النسخة الأولى في 4 يونيو، والإصدار المستقر متوقّع بين سبتمبر وأكتوبر. الجديد هنا ما هو مجرّد قائمة مزايا — فيه اتجاه واضح: شغل عاش سنين في طبقة التطبيق يرجع مكانه الطبيعي، داخل المحرّك نفسه.

المشكلة: طبقة التعويض تكبر مع كل مشروع

أي فريق اشتغل على منتج جدّي عنده كود مكتوب لتغطية نقص في SQL نفسه:

• الـ upsert المزدوج: تحاول تُدخل صفًا، يفشل بسبب تعارض، فترجع تسوّي SELECT عشان تجيب الصف الموجود. رحلتان للشبكة، وبينهما نافذة سباق (race).
• تأخّر النسخ المقروءة: تكتب على الأساسي وتقرأ من الـ replica، فيطلع للمستخدم بياناته القديمة مباشرة بعد ما حفظ. الحل المعتاد: توجيه القراءة للأساسي لفترة، أو sticky sessions — كلها ترقيع.
• التاريخ الزمني: تبي تعدّل سعرًا لفترة محدّدة فقط، فتبني جداول تاريخ يدوية وتكتب منطق تقسيم الفترات بنفسك.

كل واحد من هذي حلول شغّالة، لكنها كود إضافي يحتاج اختبارًا وصيانة، وكل سطر منه احتمال خطأ.

ما الذي تغيّر في 19

قراءة نتيجة الـ upsert بلا رحلة ثانية. صار متاحًا INSERT ... ON CONFLICT DO SELECT ... RETURNING، فيرجع لك الصف الموجود عند التعارض بدل ما ترجع فاضي وتستعلم من جديد.

اتساق «اقرأ ما كتبت» على النسخ المقروءة. أمر WAIT FOR LSN يخلّي النسخة المقروءة تنتظر حتى تلحق نقطة محدّدة في سجل الكتابة قبل تنفيذ الاستعلام.

تعديل زمني معياري. بند FOR PORTION OF صار مدعومًا في UPDATE وDELETE، مكمّلًا قيود الفترات الزمنية اللي نزلت في PostgreSQL 18.

وفوق ذلك: GROUP BY ALL، ودمج وتقسيم الأقسام عبر ALTER TABLE ... MERGE PARTITIONS وSPLIT PARTITIONS، وأمر REPACK ... CONCURRENTLY، وautovacuum متوازٍ، وتحسين يصل إلى الضعف على الإدخال مع فحوصات المفاتيح الأجنبية، إضافة إلى استعلامات الرسوم البيانية عبر SQL/PGQ.

مثال عملي

-- قبل: رحلتان + نافذة سباق
INSERT INTO customers (email, name)
VALUES ('sara@example.com', 'سارة')
ON CONFLICT (email) DO NOTHING
RETURNING id;
-- إذا رجع فاضي، تضطر لاستعلام ثانٍ

-- في 19: رحلة واحدة، والصف الموجود يرجع لك
INSERT INTO customers (email, name)
VALUES ('sara@example.com', 'سارة')
ON CONFLICT (email) DO SELECT
RETURNING id, email, created_at;

وللقراءة مباشرة بعد الكتابة:

-- على الأساسي، بعد الكتابة
SELECT pg_current_wal_insert_lsn();   -- '0/3A1F0C8'

-- على النسخة المقروءة، قبل الاستعلام
WAIT FOR LSN '0/3A1F0C8';
SELECT id, total FROM orders WHERE customer_id = 42;

والتعديل الزمني على فترة محدّدة فقط:

UPDATE prices
FOR PORTION OF valid_period
  FROM DATE '2026-08-01' TO DATE '2026-09-01'
SET amount = amount * 0.9
WHERE sku = 'ABC-123';

ملاحظات من الواقع

• بيتا يعني بيتا. لا تُشغّلها على إنتاج. الاستخدام الصحيح لهذي المرحلة: نسخة من بياناتك، واستعلاماتك الحقيقية، وتقرير بأي سلوك غريب.
• `WAIT FOR LSN` ما هو سحر. لازم تمرّر الـ LSN من الكاتب إلى القارئ عبر سياق الطلب (هيدر أو كوكي)، وتحدّد مهلة وخطة احتياطية للرجوع إلى الأساسي.
• JIT صار معطّلًا افتراضيًا. الاستعلامات التحليلية الثقيلة اللي كانت تستفيد منه تحتاج تفعيلًا صريحًا وقياسًا قبل وبعد.
• الأمن تغيّر أيضًا: مصادقة RADIUS أُزيلت، وmd5 صار يُصدر تحذيرات عند النجاح. راجع pg_hba.conf قبل الترقية.
• `default_toast_compression` صار `lz4` افتراضيًا.
• الترقية بين الإصدارات الرئيسية مشروع، لا أمر. تحتاج pg_upgrade أو pg_dump/pg_restore، وتُخطَّط في التقويم — تمامًا مثل ما اتّجهت مشاريع أخرى إلى جدولة تحديثاتها بدل مفاجأة الفريق، كما في برنامج إصدارات Next.js الأمنية.

الخلاصة

الاتجاه في PostgreSQL 19 أوضح من أي ميزة منفردة: كل ما انتقل منطق صحّة البيانات من التطبيق إلى المحرّك، ضاقت المساحة اللي يدخل منها الخطأ. الوقت المناسب لقراءة ملاحظات الإصدار وتجربة البيتا على نسخة من بياناتك هو الآن — قبل وصول الإصدار المستقر في الخريف.

المصدر الأساسي: إعلان PostgreSQL 19 Beta 2 وإعلان Beta 1 من مشروع PostgreSQL.