Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plpgsql: correctly handle parsing errors #112200

Merged
merged 3 commits into from
Oct 17, 2023

Conversation

DrewKimball
Copy link
Collaborator

plpgsql: correctly handle parsing errors

This patch ensures that PLpgSQL parsing errors are correctly propagated
in all cases. Previously, there were a few cases (like variable declaration
type parsing) where an error didn't halt parsing. The contract for
GetTypeFromValidSQLSyntax is also clarified, since it is ok to call with
an invalid type name as long as the error is properly handled.

Informs #105254

Release note: None

plpgsql: handle multiple expressions when one expression is expected

Previously, the PLpgSQL parser could panic when the user supplied more
than one expression in a location where only one was expected, for example,
in a return statement. This was because the PLpgSQL parser delegated to
the SQL parser's ParseExpr function, which expects exactly one input
expression. This commit returns a syntax error instead of the panic by
switching to use ParseExprs, which can handle multiple input expressions.

Informs #109342

Release note: None

plpgsql: return correct error for invalid parantheses and missing expression

This patch fixes error messages in the PLpgSQL parser for the case when
the parenthesis nesting is invalid, and for the case when no expression
(or statement) is supplied. Previously, invalid parentheses would cause
a panic without an error code, and a missing expression had the incorrect
message, since it wasn't checked until the SQL parser attempted to read
an empty string. Now, both cases are checked immediately by the PLpgSQL
parser and the correct error is propagated.

Fixes #109342

Release note: None

@DrewKimball DrewKimball requested review from mgartner and a team October 11, 2023 21:24
@DrewKimball DrewKimball requested a review from a team as a code owner October 11, 2023 21:24
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Collaborator

@rharding6373 rharding6373 left a comment

Choose a reason for hiding this comment

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

:lgtm: Nice work! Only one very minor test suggestion.

Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball and @mgartner)


pkg/sql/plpgsql/parser/testdata/stmt_assign line 68 at r3 (raw file):

DECLARE
BEGIN
  a := 1, (2, 3, 4, 5);

nit: have one of these tests return 3+ columns.

Copy link
Collaborator Author

@DrewKimball DrewKimball left a comment

Choose a reason for hiding this comment

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

Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)


pkg/sql/plpgsql/parser/testdata/stmt_assign line 68 at r3 (raw file):

Previously, rharding6373 (Rachael Harding) wrote…

nit: have one of these tests return 3+ columns.

Done.

@DrewKimball
Copy link
Collaborator Author

TFTR!

Copy link
Collaborator

@mgartner mgartner left a comment

Choose a reason for hiding this comment

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

:lgtm: Nice finds!

Reviewed 2 of 3 files at r1, 7 of 7 files at r4, 2 of 2 files at r5, 7 of 7 files at r6, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (and 1 stale) (waiting on @DrewKimball)

This patch ensures that PLpgSQL parsing errors are correctly propagated
in all cases. Previously, there were a few cases (like variable declaration
type parsing) where an error didn't halt parsing. The contract for
`GetTypeFromValidSQLSyntax` is also clarified, since it is ok to call with
an invalid type name as long as the error is properly handled.

Informs cockroachdb#105254

Release note: None
Previously, the PLpgSQL parser could panic when the user supplied more
than one expression in a location where only one was expected, for example,
in a return statement. This was because the PLpgSQL parser delegated to
the SQL parser's `ParseExpr` function, which expects exactly one input
expression. This commit returns a syntax error instead of the panic by
switching to use `ParseExprs`, which can handle multiple input expressions.

Informs cockroachdb#109342

Release note: None
…ression

This patch fixes error messages in the PLpgSQL parser for the case when
the parenthesis nesting is invalid, and for the case when no expression
(or statement) is supplied. Previously, invalid parentheses would cause
a panic without an error code, and a missing expression had the incorrect
message, since it wasn't checked until the SQL parser attempted to read
an empty string. Now, both cases are checked immediately by the PLpgSQL
parser and the correct error is propagated.

Fixes cockroachdb#109342

Release note: None
@DrewKimball DrewKimball added the backport-23.2.x Flags PRs that need to be backported to 23.2. label Oct 17, 2023
@DrewKimball
Copy link
Collaborator Author

bors r+

@craig
Copy link
Contributor

craig bot commented Oct 17, 2023

Build succeeded:

@craig craig bot merged commit 45f6344 into cockroachdb:master Oct 17, 2023
@DrewKimball DrewKimball deleted the plpgsql-bug-fix branch October 17, 2023 05:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-23.2.x Flags PRs that need to be backported to 23.2.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

sql: v23.1.8-custom: parentheses is badly nested in ParseAndCollectTelemetryForPLpgSQLFunc
4 participants