LL言語やWebフレームワークの PostgreSQL対応 〜DBの機能がユーザーに届くまで〜

第57回 PostgreSQLアンカンファレンス@オンライン

2026-09-03 21:40 -
https://pgunconf.connpass.com/event/402653/

Transcript

1. LL言語やWebフレームワークの PostgreSQL対応 〜DBの機能がユーザーに届くまで〜 第57回 PostgreSQLアンカンファレンス@オンライン 武田 憲太郎 / @KentarouTakeda
2. 自己紹介 武田 憲太郎 / @KentarouTakeda Webアプリケーション開発者 / OSSコントリビューター • PostgreSQLユーザー歴: 2001年〜 • Webアプリケーションのバックエンドとして利用 • Laravelコントリビューター: 2022年〜 • Eloquent ORMが中心 • PHP本体（php-src）コントリビューター: 2024年〜 • pdo̲pgsql（SQL抽象化レイヤーの PostgreSQLドライバ）が主 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 2
3. ドライバ開発を通じて見えた課題感 PostgreSQLの機能がLL言語のユーザーに届くまで（PHPの場合） API PostgreSQL PQsetSingleRowMode() 9.2 / 2012年 ext/pgsql libpqラッパ pdo_pgsql 抽象化層 非対応 2025年（13年） PQenterPipelineMode() 14 / 2021年 断念（2023年） 非対応 PQsetChunkedRowsMode() 17 / 2024年 2024年11月（2ヶ月） 2026年11月予定 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 3
4. pdo̲pgsqlでのチャンクフェッチ対応 $statement = $pdo->prepare( 'SELECT * FROM bench', [Pdo¥Pgsql::ATTR_CHUNK_SIZE => 1000] ); 対応PR: php/php-src#23210 （2026年11月 PHP 8.6 リリース予定） 補足: pdo̲pgsql（SQL抽象）ではなく ext/pgsql（libpqラッパ）は2024年11月に対応 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 4
5. 対応前の予想と現実 予想: 数日で対応できるはず • 単一行モードの拡張で良いはず • PQsetChunkedRowsMode() のラッパー 現実: 所要時間2週間以上 → 対応完了後の延長戦 • 対応中に既存機能のバグをいくつか発見 • バグの共通項は「状態管理」 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 5
6. フロントエンド側カーソル制御の既存バグ修正 • まだバックエンドに送っていない文を破棄 • バックエンドがエラーとして拒否した文を破棄 • エラー状態のトランザクション内での CLOSE 文 • ロールバックされた WITH HOLD カーソルの解放 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 6
7. COPY とそれ以外との競合 PQresultStatus が致命的なエラーを示した場合 であっても、libpqがエラー情報を完全に処理でき るようにNULLポインタが返されるまで PQgetResult を呼び出さなければなりません。 PostgreSQL 18.4文書 32.4. 非同期コマンドの処理 より 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 7
8. COPY とそれ以外との競合（実例） • COPY_* 状態の drain はビジーループでハング • 多くの言語やツールがこのバグを経験している • pgbenchはこのバグを6年間抱えていた • psqlは堅牢化のつもりでこのループを呼び込んだ • COPY と PQsetChunkedRowsMode() 組み合わせ • ここを「入口」に様々なものを見つける • COPY と PQsetSingleRowMode() 組み合わせ • 既存バグを直さないと新機能を実装できない 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 8
9. 対応が断念されたパイプラインモード • 2023年3月: ext/pgsql パイプラインモード対応 • php/php-src#10868 • 2023年11月: PHP 8.3 GAの3日前にリバート • php/php-src#12735 • 再導入の動きはなく現在も非対応 「libpqの薄いラッパ」が既存の状態管理を壊し、 メンテナもレビュアーもそのことに気づかなかった 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 9
10. パイプラインモード: 他の言語やライブラリの状況 • node-postgres（古いが非同期前提） • 2021年11月: Issueからの要望 • （複数のPRが頓挫した末に） • 2026年8月: 対応 • psycopg3（リライト） • 2022年8月: 対応（3.1でPipeline mode） 「接続の状態」を設計に織り込んだライブラリは 実装成功に至る 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 10
11. バックエンド側の機能追加がユーザーに届かない • DBドライバは「初期に作られる」 • 「一度作ったらそう変えられない」領域 • 抽象化レイヤーを上るほど対応に時間がかかる • ドライバ → 言語 → ライブラリ → FW 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 11
12. WebアプリケーションFWの存在 • Web系プログラマーの多くは FWを通じてアプリを書いている • マルチDB対応のFWにベンダー固有機能を 入れるのはそれなりの理由が要る • 言語側も、FWの対応状況に モチベーションが左右される 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 12
13. PostgreSQLの躍進（Laravelの場合） • 旧来: 「マルチDB対応が可能なら入れる」 • json演算子・全文検索・幾何データ型など • 最近: pgvectorがブレイクスルー • 2026年 コサイン距離: <=> をラップした様々なAPI • PostgreSQL先行 • 現在: 「DB依存機能も、有用なら入れる」 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 13
14. 立場ごとの考え • Webアプリケーション開発者 • DBレイヤーの高度な機能を業務アプリに持ち込むのは避けたい • ただし、便利な機能なら使わせて欲しい、ごくシンプルに • FWのコントリビューター • マルチDB対応製品は、デザインが難しくマージの障壁も高い • LL言語のコントリビューター • FW側の対応が見えないとモチベーションを保ちづらい • バックエンド開発者 • 皆さんの考えを教えてください • 新機能やAPIを検討する時、何を重視し、 どんなクライアント実装を想定しますか？ 2026/9/3 LL言語やWebフレームワークのPostgreSQL対応 14
15. ユーザー あるいは 別レイヤーの開発者の立場から 見えた景色を共有しました ありがとうございました