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-23T00:22:22Z
Lists: pgsql-hackers
On Tue, Aug 20, 2024 at 02:33:23PM -0400, Tom Lane wrote: > I wrote: >> Yeah, I was wondering about that. I wouldn't do it exactly like >> that, but with a check that the entry gets matched somewhere. > > Here's a patch for that (again based on the other patch series). > This did not turn up anything interesting, but it's probably > worth keeping. Okay, I see where you're going with this one. It does not seem like this is going to cost much in long-term maintenance while catching unfortunate issues, so +1 from me. The patch does not apply on HEAD due to the dependency with the other things you are proposing, and I would have hardcoded failures to check that the reports are correct, but that looks neat on read. -- Michael
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