Re: pg_get_constraintdef() doesn't always give an equal constraint
От | Jon Jensen |
---|---|
Тема | Re: pg_get_constraintdef() doesn't always give an equal constraint |
Дата | |
Msg-id | alpine.LFD.2.11.1503281718060.3788@ybpnyubfg6.ybpnyqbznva6 обсуждение исходный текст |
Ответ на | Re: pg_get_constraintdef() doesn't always give an equal constraint (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_get_constraintdef() doesn't always give an equal constraint
|
Список | 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 по дате отправления: