Re: pg_get_constraintdef() doesn't always give an equal constraint - Mailing list pgsql-bugs

From Jon Jensen
Subject Re: pg_get_constraintdef() doesn't always give an equal constraint
Date
Msg-id alpine.LFD.2.11.1503281718060.3788@ybpnyubfg6.ybpnyqbznva6
Whole thread Raw
In response to Re: pg_get_constraintdef() doesn't always give an equal constraint  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_get_constraintdef() doesn't always give an equal constraint
List pgsql-bugs
On Sat, 28 Mar 2015, Tom Lane wrote:

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

Well, as part of the standard regression test suite it's comparing stored
expected output with newly-generated output, like all the other tests. I
must be misunderstanding what you mean because nothing manual about that,
is there?

> I wonder whether there isn't a more direct way of testing whether each
> output re-parses to the same node tree.

That would be nice: Perhaps a function to parse into a node tree. But I'm
not aware of anything like that existing and it seems it would require
creating a node tree datatype to put the parse result into, to then feed
to a new deparse function variant.

Jon

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_get_constraintdef() doesn't always give an equal constraint
Next
From: Peter Eisentraut
Date:
Subject: Re: Problem when installing PL/Proxy with Windows OS