Re: Improving the notation for ecpg.addons rules

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-08-19T05:17:34Z
Lists: pgsql-hackers
On Sun, Aug 18, 2024 at 01:13:36PM -0400, Tom Lane wrote:
> While I've not done it in the attached, perhaps it would be
> 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.

Not being too aggressive with the changes sounds like a good thing
here.

> 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?

Seeing changes like "stmtClosePortalStmt" changing to "stmt
ClosePortalStmt" is clearly an improvement in readability.
SignedIconstIconst was also fun.  Your change is a good idea.

It looks like %replace_line expects all its elements to have one space
between each token, still this is not enforced with a check across its
hardcoded elements?
--
Michael

Commits

  1. ecpg: invent a saner syntax for ecpg.addons entries.

  2. ecpg: add cross-checks to parse.pl for usage of internal tables.