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.1503301011450.2321@ybpnyubfg6.ybpnyqbznva6
Ответ на
Список
Дерево обсуждения
pg_get_constraintdef() doesn't always give an equal constraint Jeff Davis <pgsql@j-davis.com>
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 Jon Jensen <jon@endpoint.com>
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 Jon Jensen <jon@endpoint.com>
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 Stephen Frost <sfrost@snowman.net>
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 Stephen Frost <sfrost@snowman.net>
Re: pg_get_constraintdef() doesn't always give an equal
constraint Jon Jensen <jon@endpoint.com>
Re: pg_get_constraintdef() doesn't always give an equal constraint Jeff Davis <pgsql@j-davis.com>
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 Jeff Davis <pgsql@j-davis.com>
Re: pg_get_constraintdef() doesn't always give an equal constraint Tom Lane <tgl@sss.pgh.pa.us>
On Sun, 29 Mar 2015, Tom Lane wrote: > Jon Jensen writes: >> On Sat, 28 Mar 2015, Tom Lane wrote: >>> 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? > > My point is that the expected output has to be manually checked initially > to see if it's right or not; and since it often doesn't look exactly like > the original SQL, that checking is painful and not foolproof. Oh, I see what you mean. I'm going from the assumption that a new regression test is useful even if it starts life documenting only the current behavior, without any idea of whether that was or is correct by some outside standard. I think we should know if the parse/deparse round-trip changes behavior due to some change, regardless of whether it's better or worse. The regression test should call our attention to it and then we can spend the human cycles to investigate whether it's better now, or worse. In any case, the difference could cause trouble for people who depended on the old behavior, even if the new is ostensibly better. > It's interesting to consider something like the COPY_PARSE_PLAN_TREES > #define, which inserts code into the backend to see whether copyfuncs.c > and equalfuncs.c are sane or not. Running the regression tests with > that turned on provides pretty thorough coverage of those modules. Maybe that's the way to go, then, if it avoids the necessity of creating all those tables with CHECK constraints, since we don't have a user-accessible parse function. Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/
В списке pgsql-bugs по дате отправления
От: Tom Lane
Дата:
От: Tom Lane
Дата: