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 обсуждение исходный текст |
Ответ на | Re: pg_get_constraintdef() doesn't always give an equal constraint (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Sun, 29 Mar 2015, Tom Lane wrote: > Jon Jensen <jon@endpoint.com> 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 по дате отправления: