PostgreSQL 18 generated virtual columns require STORED
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 73/100
Research direction
Start at the PostgreSqlDialect handling for generated columns and reproduce the supplied CREATE TABLE statement with an omitted mode. Ensure PostgreSQL 18 virtual generated columns are accepted, then add or run regression coverage showing that the statement parses successfully without requiring STORED.
Written by the indexing model from the issue text.
Description
Summary
PostgreSqlDialect rejects PostgreSQL 18 generated columns when the generated-column mode is omitted.
PostgreSQL 18 supports both stored and virtual generated columns. Per the PostgreSQL 18 docs, generated columns are virtual by default and VIRTUAL / STORED are optional explicit mode keywords:
https://www.postgresql.org/docs/current/ddl-generated-columns.html
Reproduction
Using sqlparser 0.62.0 with PostgreSqlDialect, parse:
CREATE TABLE users (
first_name text NOT NULL,
last_name text NOT NULL,
name character varying(255)
GENERATED ALWAYS AS (((first_name || ' '::text) || last_name))
NOT NULL
);
Expected behavior
The statement parses successfully, with name represented as a generated virtual column. Since PostgreSQL 18 defaults generated columns to virtual, omitted mode should be accepted as virtual or at least accepted with no explicit mode.
Actual behavior
Parsing fails with:
sql parser error: Expected: STORED, found: NOT
This also affects PostgreSQL 18 pg_dump output, which emits generated virtual columns without an explicit VIRTUAL keyword, for example:
name character varying(255) GENERATED ALWAYS AS (((first_name || ' '::text) || last_name)) NOT NULL
Notes
GenericDialect can parse a variant when VIRTUAL is made explicit, but PostgreSqlDialect currently appears to require STORED after GENERATED ALWAYS AS (...).
- Dominant language
- Rust
- Stars
- 3.5k
- Forks
- 774
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 19
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/datafusion-sqlparser-rs
-
Difficulty 2/5 1-2 days Newbie friendliness 72/100
apache/datafusion-sqlparser-rs#2495 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/datafusion-sqlparser-rs#2461 · 2 comments ·
-
Add SQL/PGQ keywords Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
apache/datafusion-sqlparser-rs#2393 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
apache/datafusion-sqlparser-rs#2390 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
apache/datafusion-sqlparser-rs#1761 ·
All issues in apache/datafusion-sqlparser-rs
Similar issues
-
todo:perf
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Openstate:needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zed-industries/zed#64611 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
objectionary/phie#154 ·