[feature request] PostgreSQL: FOR NO KEY UPDATE / FOR KEY SHARE, PREPARE TRANSACTION family and DO blocks have no AST production

未關閉
  • 哪裡不對？
#2,914 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
35/100
Issue 類型
功能
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
postgresql, rust
領域
backend-api-design

研究方向

Start with src/ast/mod.rs and the PostgreSQL parser under src/parser/**; compare the existing FOR UPDATE / FOR SHARE locking clause and PREPARE statement productions. Add AST support and parsing for the missing locking strengths, prepared transaction statements, and DO blocks, then verify they produce matchable AST nodes with PostgreSqlDialect.

由索引模型根據 Issue 內容生成。

描述

PostgreSQL

Summary

sqlparser-rs 0.64.0 parses SELECT ... FOR UPDATE / FOR SHARE, but has no production for the other two PostgreSQL row-lock strengths, and no production for any PostgreSQL two-phase-commit statement or the anonymous DO block. These are the four surfaces PostgreSQL's own regression/isolation suites exercise and they cannot be reached through the AST at all.

Environment

  • sqlparser 0.64.0 (crate source, src/ast/mod.rs, src/parser/**)
  • PostgreSQL dialect (PostgreSqlDialect)
  • Consumer: a PostgreSQL-wire-compatible engine driving REL_16_4 pg_regress + isolation suites against sqlparser's AST

What is missing

PostgreSQL statement Expected Actual (0.64.0)
SELECT ... FOR NO KEY UPDATE a locking-clause AST node no production; FOR UPDATE and FOR SHARE only
SELECT ... FOR KEY SHARE a locking-clause AST node no production
PREPARE TRANSACTION 'gid' a statement node no production
COMMIT PREPARED 'gid' / ROLLBACK PREPARED 'gid' statement nodes no production
DO $$ ... $$ (anonymous code block) a statement node no Statement::Do variant

Evidence (0.64.0 crate source)

  • for no key update / for key share: 0 matches anywhere under src/ (case-insensitive, whitespace-tolerant).
  • PREPARE TRANSACTION: 0 matches anywhere under src/.
  • pub enum Statement has 151 variants; the only matches for the interesting prefixes are Prepare (the SQL PREPARE name AS ... statement), Lock, LockTables (MySQL) — there is no Do and no prepared-transaction variant.

Expected behaviour

Parsing the statements above with PostgreSqlDialect yields a statement/locking-clause node the consumer can match on, the same way SELECT ... FOR UPDATE already does.

Actual behaviour

The parser rejects them, so a downstream engine cannot represent the feature through the AST and is forced either to pre-scan the SQL text (which is what we want to avoid) or to leave the feature unimplemented.

Why it matters here

pg_regress's lock, select and transactions files and the isolation suite's prepared-transactions*, lock-committed-*, nowait-*, skip-locked-* specs all start with these statements. Without an AST face, the consumer cannot answer them at all.

主要語言
Rust
星號
3.5k
分支
805
平均合併
2 天 3 小時
30 天內合併 PR
116

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 有 Pull Request 範本
  • 沒有貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

apache/datafusion-sqlparser-rs 的其他 Issue

查看 apache/datafusion-sqlparser-rs 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。