Re: [PATCH] regression test: view and rule definitions must round trip

Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> On Mon, Oct 26, 2026 at 7:43 PM Greg Burd <greg(at)burd(dot)me> wrote:
>> I'm not sure what you're suggesting, yes that is true but does that mean
>> that you'd prefer that method for validation over what I've proposed?

> I am simply pointing out that a test which you said doesn't exist
> above. I would rather use that infrastructure (which works for objects
> other than views as well) that creating a new one specifically for
> views. If we could build a better way to do this for all objects, that
> would be great. That possibility has been discussed earlier.

I share Ashutosh's doubts about whether this is a better way than the
existing pg_dump round-trip test. It is cute that you try to actually
execute the re-parsed view and see if the results are the same; the
existing methodology does nothing in that direction. But with such
necessarily-restricted input data I'm not sure how much that proves
really.

To my mind the biggest problems we've had with ruleutils bugs are

(1) Failure to think about, or to test, dumping of new syntax at all.
Unfortunately this approach doesn't help that, because if you've
overlooked the issue then you won't think to add a new test case
here either.

(2) Unexpected interactions between syntax features, such as the
parenthesization bugs that Henson Choi is working through on
nearby threads. I don't see that this approach moves us very far
on that problem either, because it does little about combining
different features. A brute force approach to that would be O(N^2)
or worse, so I'm not sure how much can be done automatically.

More generally, I'm not really convinced that I like this black-box
approach to testing ruleutils behavior. In places such as rules.sql's
related tests, we're interested in whether the output is stable
across branches and looks reasonable to a human; neither thing can
be determined with this test, since it intentionally hides the
deparsed output.

regards, tom lane