The problem I was trying to solve was the total lack of configurability.
> Most/all of what you’ve decided to allow to be ignored has no variability based on setting values or environment - and likely would be stuff we wouldn’t want to be optional.
Now that you can see why my approach wouldn't work, could you suggest an improvement on that? maybe different directives?
We could go for regular expressions, but I tried to give something simpler before, and get feedback.
Could you please modify my README.md pretending you have something that works, then I see if I can make it work. We could read compile options if you want, or extract postgres default parameters. Embed blocks of code to generate the output and so on.
If those tests are impossible to fix in regress/sql, should they be promoted to TAP?
Maybe the tests are easy to fix, e.g. INSERT INTO toasttest values (repeat('1234567890',300)); expects toasting, instead of 300 it should use something based on current_setting(...), or set the minimum toast length on the table.
In my regression it was just 30 failures, bad but not so bad.
Thank you for your input David
Alexandre
On Saturday, February 21, 2026, Alexandre Felipe <o.alexandre.felipe@gmail.com> wrote:
(I personally think that we could have the input and expected output in one single file).
Even if we could why would that be an improvement - green-field, let alone the motivation for refactoring.
By default it ignores comments and spaces, and in the expected file you can enable/disable other things, e.g. ignoring numbers in specific lines would probably help with the 32kB failures.
What’s the minimum functionality you’d need to get block size variances to be auto-accepted using existing expected outputs. Most/all of what you’ve decided to allow to be ignored has no variability based on setting values or environment - and likely would be stuff we wouldn’t want to be optional (i.e., you need to justify each option). And there is no demonstration of actually solving the problem at hand.
I’d also go for an approach like: if block size <> 8kb then re-process any exception output diffs/files again using the looser constraints. Otherwise, stop and report test failure (status quo). I’d be against applying these kinds of bypasses to stock configured PostgreSQL for which a complete set of copy-and-pasted expected files need to exist.
David J.
