Jon Jensen <jon@endpoint.com> writes:
> On Mon, 23 Mar 2015, Tom Lane wrote:
>> A larger issue is that I have a nasty feeling that this isn't the
>> only place where ruleutils.c output might be read in a way that's
>> functionally equivalent to the original, but not the exact same
>> parsetree.
> Jeff pointed this out to me and as we discussed it, it seems like a good
> time to add a regression test to make us aware of the current parse +
> deparse behavior, and call attention to any changes in that behavior
> later.
> Attached is a Perl script that generates many combinations of CHECK
> constraints like Jeff's, but with various types, and the result of running
> it in the regression test suite.
> Would something like this be welcome in the regression test suite?
I can't really see adding something like this to the regression tests;
the value per cycle expended, over the long term, just isn't there IMO.
We could possibly use this approach as a one-shot test for vetting a
proposed patch ... but as you've got it set up, it seems like it requires
manual inspection of each output to see if it's OK or not, which isn't
all that helpful. I wonder whether there isn't a more direct way of
testing whether each output re-parses to the same node tree.
regards, tom lane