Re: Improving the notation for ecpg.addons rules

2024-10-14 Thread Tom Lane
I wrote: > Anyway, my thought was to merge this into the other patch series, > but I didn't do that yet. I'd forgotten about merging these two patches into the bigger ecpg patch series. Since there didn't seem to be any objection to either, I went ahead and pushed them. r

Re: Improving the notation for ecpg.addons rules

2024-08-22 Thread Tom Lane
Michael Paquier writes: > 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. I did test it by injecting errors, but I don't see why we'd leave t

Re: Improving the notation for ecpg.addons rules

2024-08-22 Thread Michael Paquier
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 anyt

Re: Improving the notation for ecpg.addons rules

2024-08-20 Thread Tom Lane
I wrote: > Michael Paquier writes: >> 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? > Yeah, I was wondering about that. I wouldn't do it exactly like > that, but with a check

Re: Improving the notation for ecpg.addons rules

2024-08-18 Thread Tom Lane
Michael Paquier writes: > 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? Yeah, I was wondering about that. I wouldn't do it exactly like that, but with a check that the entry ge

Re: Improving the notation for ecpg.addons rules

2024-08-18 Thread Michael Paquier
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 alternativ

Improving the notation for ecpg.addons rules

2024-08-18 Thread Tom Lane
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 thing