[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 摘要。