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.
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.
regards, tom lane
