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

On Monday, October 26th, 2026 at 3:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Fair points. I see the objection clearly now, thanks for writing it up.
I saw a repeating theme and took a stab at creating a way to capture it.
Seems that it was miss.

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

Yes, on this we agree. Somehow I'd imagined that having something
simple and central would add some awareness of the issue earlier in the
process.

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

Yes, I've seen his good work in that regard.

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

I differ here in that I do like a clean wrapped interface that
encapsulates a kind of test making it a) easier to contribute, b) more
prominent as a failure type that we should cover, and c) less verbose.

I like the simple worked/didn't work style of this, but that's just me.

> regards, tom lane

It sounds like I should drop this idea, and focus on other things and/or
helping Choi in his efforts. And that's a good outcome too. :)

best.

-greg