From: | Jon Jensen <jon(at)endpoint(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: pg_get_constraintdef() doesn't always give an equal constraint |
Date: | 2015-03-28 23:18:19 |
Message-ID: | alpine.LFD.2.11.1503281718060.3788@ybpnyubfg6.ybpnyqbznva6 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2015-03-29 14:15:44 | Re: Problem when installing PL/Proxy with Windows OS |
Previous Message | Tom Lane | 2015-03-28 19:32:27 | Re: pg_get_constraintdef() doesn't always give an equal constraint |