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/
