Improving the notation for ecpg.addons rules
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2024-08-18T17:13:36Z
Lists: pgsql-hackers
Attachments
- v1-saner-ecpg.addons-syntax.patch (text/x-diff) patch v1
I've gotten annoyed by the notation used for ecpg.addons rules,
in which all the tokens of the gram.y rule to be modified
are just concatenated. This is unreadable and potentially
ambiguous:
ECPG: fetch_argsABSOLUTE_PSignedIconstopt_from_incursor_name addon
The attached draft patch changes things so that we can write
ECPG: addon fetch_args ABSOLUTE_P SignedIconst opt_from_in cursor_name
which is a whole lot closer to what actually appears in gram.y:
fetch_args: cursor_name
...
| ABSOLUTE_P SignedIconst opt_from_in cursor_name
(Note that I've also moved the rule type "addon" to the front.
This isn't strictly necessary, but it seems less mistake-prone.)
While I've not done it in the attached, perhaps it would be
an improvement to allow a colon after the target nonterminal:
ECPG: addon fetch_args: ABSOLUTE_P SignedIconst opt_from_in cursor_name
to bring it even closer to what is written in gram.y. You could
imagine going further and writing this case as something like
ECPG: addon fetch_args | ABSOLUTE_P SignedIconst opt_from_in cursor_name
but I think that might be a step too far. IMO it's not adding much
readability, and it seems like introducing an unnecessary dependency
on exactly how the gram.y alternatives are laid out.
BTW, the attached patch won't apply to HEAD, it's meant to apply
after the patch series being discussed at [1]. So I won't stick
this in the CF yet.
Thoughts?
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/2011420.1713493114@sss.pgh.pa.us
Commits
-
ecpg: invent a saner syntax for ecpg.addons entries.
- dbedc461b4e7 18.0 landed
-
ecpg: add cross-checks to parse.pl for usage of internal tables.
- d2f41b4621de 18.0 landed