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 Sun, Feb 22, 2026 at 2:19 AM David G. Johnston <
[email protected]> wrote:
> On Saturday, February 21, 2026, Alexandre Felipe <
> [email protected]> 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.
>
>
