Skip to content

Adding support for PostgreSQL's XML functions#2252

Open
LucaCappelletti94 wants to merge 3 commits intoapache:mainfrom
LucaCappelletti94:postgres-regression-7
Open

Adding support for PostgreSQL's XML functions#2252
LucaCappelletti94 wants to merge 3 commits intoapache:mainfrom
LucaCappelletti94:postgres-regression-7

Conversation

@LucaCappelletti94
Copy link
Copy Markdown
Contributor

This PR adds PostgreSQL XML expression support to sqlparser-rs by introducing dedicated AST variants (Expr::Xml*) and parser paths for XMLCONCAT, XMLELEMENT, XMLFOREST, XMLPARSE, XMLPI, XMLROOT, and XMLSERIALIZE, aligned with PostgreSQL XML function syntax (PostgreSQL XML functions)

Implementation is intentionally enabled for both PostgreSqlDialect and GenericDialect, while non-target dialects keep treating xml* names as ordinary function identifiers and reject XML-special grammar forms.

The test updates explicitly lock these dialect boundaries, add AST-shape coverage for all new XML nodes, and prefer structural assertions over formatting-sensitive string checks.

This PR DOES NOT add support for XML parsing of course, which remains something that the user should validate, since PostgreSQL itself will accept (and fail at runtime) queries with invalid XML. Whether we should raise errors there is debatable.

@LucaCappelletti94 LucaCappelletti94 marked this pull request as ready for review February 27, 2026 10:29
// an unary negation `NOT ('a' LIKE 'b')`. To solve this, we don't accept the
// `type 'string'` syntax for the custom data types at all.
DataType::Custom(type_name, modifiers)
if dialect_of!(self is PostgreSqlDialect | GenericDialect)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use a dialect method for this?

Copy link
Copy Markdown
Contributor

@yoavcloud yoavcloud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @LucaCappelletti94. There are many more changes in this PR than are required to address the missing functionality, which makes code review harder.

I'm all for using coding agents to speed up the development of the project, but the bottleneck now becomes reviewing the PRs.

We should come up with guidelines for the proper usage of coding agents and I will do my best to advance this with the project members. In the meantime, can you please prepare a lighter version of this change?

@LucaCappelletti94
Copy link
Copy Markdown
Contributor Author

TLDR: I was trying to add these missing features as fast as the postgres differential fuzzer I had was finding them, and I ended up rushing bad code. Then the fuzzer found some goldmine of hundreds of missing things (which I decided to not look into it for the time) and I gave up with the PR series. I will explode this PR in tiny focused ones.

I will publish that fuzzer in another repo so that it can be used to gauge completes. It is nothing fancy, just honggfuzzer seeded with Postgres corpus of statements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants