Repository navigation
Conversation
The paren_expr printer collapses nested parentheses into one pair. When
the inner pair belongs to a subquery or a row constructor and the outer
pair is part of the enclosing clause, both are required, and dropping
one gives invalid SQL:
CREATE POLICY admin_only ON permissions
USING ((SELECT is_admin FROM users WHERE name = current_user))
was formatted with USING (SELECT ...), which PostgreSQL rejects. The
same happened with GENERATED ALWAYS AS ((SELECT ...)) and with a row in
PARTITION BY RANGE (((a, b))).
Nested parentheses are now kept when the inner ones contain a subquery
or a list.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
paren_exprprinter collapses nested parentheses into a single pair. That's fine for(((1 + 2))). But when the inner pair belongs to a subquery or a row constructor and the outer pair is part of the enclosing clause, both are needed, and the output is no longer valid SQL:is formatted with
USING (SELECT is_admin FROM users WHERE name = current_user), which PostgreSQL rejects with a syntax error atSELECT. The same thing happens with:WITH CHECK ((SELECT ...));GENERATED ALWAYS AS ((SELECT ...)) STORED;GENERATED ALWAYS AS ((a * 2, a * 3));PARTITION BY RANGE (((a, b))), which comes out asRANGE ((a, b)).Nested parentheses are still collapsed, except when the inner pair contains a subquery (
select_stmtorcompound_select_stmt) or a list. Then both pairs are kept. In plain expressions this can leave a redundant pair, as inSELECT ((SELECT 1)), but it never removes one that is needed.Test: "preserves parenthesis around subquery used as the USING condition" in
test/ddl/policy.test.ts. It fails without the change and passes with it.yarn testpasses (1060 passed, 1 skipped), as doyarn ts:checkandprettier --checkon the changed files.I found this by formatting the statements of PostgreSQL's regression tests with the
postgresqlparser and comparing the libpg_query parse tree of each output with that of the input. Together with the separate row-constructor fix (#96), the 8 statements where formatting changed the meaning through parentheses now keep it, and no other statement changed.