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