fmguerreiro opened a new pull request, #2307:
URL: https://github.com/apache/datafusion-sqlparser-rs/pull/2307

   ## Summary
   
   Adds AST types and parser support for PostgreSQL `EXCLUDE` table constraints.
   
   **Syntax supported:**
   ```sql
   [ CONSTRAINT <name> ] EXCLUDE [ USING <index_method> ]
     ( <expr> WITH <operator> [, ...] )
     [ INCLUDE (<cols>) ]
     [ WHERE (<predicate>) ]
     [ DEFERRABLE | NOT DEFERRABLE ]
     [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
   ```
   
   **Changes:**
   - `src/ast/table_constraints.rs`: new `ExclusionElement` and 
`ExclusionConstraint` structs; new `TableConstraint::Exclusion` variant with 
`Display`, `From`, and `Spanned` impls
   - `src/ast/mod.rs`: re-export `ExclusionConstraint`, `ExclusionElement`
   - `src/ast/spans.rs`: `Spanned` arm for `TableConstraint::Exclusion`
   - `src/parser/mod.rs`: parse `EXCLUDE` keyword in `parse_table_constraint`; 
new `parse_exclusion_element` helper
   - `tests/sqlparser_postgres.rs`: round-trip and AST-assertion tests 
including 2 negative cases
   
   ## Design notes
   
   **Operator representation as `String`.** The exclusion operator (e.g. `&&`, 
`<->`, `=`) is stored as `String` rather than an enum variant. PostgreSQL 
EXCLUDE constraints support any operator that satisfies the commutativity 
requirement, including extension-defined operators (e.g. `tsm_system_rows`, 
custom range types). Storing as `String` avoids needing to enumerate all valid 
operators and is consistent with how `BinaryOperator::Custom` handles unknown 
operators in this codebase.
   
   **Operator token validation.** `parse_exclusion_element` rejects `EOF`, 
`RParen`, `Comma`, and `SemiColon` as the operator token to avoid silently 
accepting structurally invalid input. The list is not exhaustive (e.g. `LParen` 
would still be accepted) — a whitelist of known operator tokens would be more 
robust but harder to maintain across operator extensions. Open to feedback if 
maintainers prefer a different approach.
   
   **Dialect gating.** The `EXCLUDE` clause is parsed in 
`parse_table_constraint` which is dialect-agnostic. If maintainers prefer to 
gate this behind something like `dialect.supports_exclude_constraints()`, happy 
to add it.
   
   ## Test plan
   
   - 10 tests in `tests/sqlparser_postgres.rs` covering: basic, multi-element, 
`WHERE` clause, `INCLUDE`, default index method, `DEFERRABLE INITIALLY 
DEFERRED`, `ALTER TABLE ADD CONSTRAINT`, full round-trip, missing-`WITH` error, 
empty-element-list error.
   
   Reference: 
https://www.postgresql.org/docs/current/sql-createtable.html#SQL-CREATETABLE-EXCLUDE


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to