Skip to content

func_arg: a param_name is followed only by an arg_class or a func_type - #13

Open
evanvolgas wants to merge 1 commit into
sqlc-dev:mainfrom
ArdentAILabs:funcarg-param-name-lookahead
Open

evanvolgas wants to merge 1 commit into
sqlc-dev:mainfrom
ArdentAILabs:funcarg-param-name-lookahead

Conversation

@evanvolgas

Copy link
Copy Markdown

argNameFollowedByType treated a type_function_name token as a param_name unless the next token closed the argument. An unnamed argument whose type starts with an unreserved keyword (DOUBLE_P PRECISION), or is followed by ARRAY, then failed to parse:

GRANT ALL ON FUNCTION f(double precision[]) TO x   -- syntax error at or near "precision"
DROP FUNCTION f(int4 ARRAY)                        -- syntax error at or near "ARRAY"

pg_dump emits the first form for every function with an unnamed float8 argument (pgvector's vector_avg, array_to_vector, etc.), so a dump of such a database could not be split.

In gram.y, func_arg follows a param_name with an arg_class or a func_type. So the token is a param_name exactly when the next token can begin one of those. The check now tests that.

Tests. cmd/regenerate gets a tier for oliphant's own regression inputs (cmd/regenerate/regressions/*.sql), and the oracle writes their parse, scan and deparse goldens. A full regenerate leaves every existing golden byte-identical. The 54 new func_arg_types cases fail without the fix and pass with it. Separately, a differential run of 2,150 argument forms against the cgo oracle (46 type spellings across 33 statement shapes, plus a real Supabase pg_dump's ACL lines) matches byte for byte, errors included. Before the fix, 144 of them differed.

argNameFollowedByType decided that a type_function_name token was a
param_name unless the next token closed the argument, so an unnamed
argument whose type begins with an unreserved keyword or is followed by
ARRAY failed to parse:

  GRANT ALL ON FUNCTION f(double precision[]) TO x
    -> syntax error at or near "precision"
  DROP FUNCTION f(int4 ARRAY)
    -> syntax error at or near "ARRAY"

pg_dump writes the first form for every function that takes a float8
argument (pgvector's vector_avg, array_to_vector, ...), so a dump of such
a database could not be split. gram.y's func_arg follows a param_name with
an arg_class or a func_type; the token is a param_name exactly when the
next token can begin one of those, which is what this now tests.

cmd/regenerate gains a tier of oliphant's own regression inputs
(cmd/regenerate/regressions/*.sql) with oracle-written parse, scan and
deparse goldens. Regenerating leaves every existing golden byte-identical;
the 54 new func_arg_types cases fail without the fix and pass with it.

Co-authored-by: Evan Volgas <evan@tryardent.com>
Signed-off-by: Evan Volgas <evan@tryardent.com>
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.

1 participant