Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified
Date
Msg-id 9305.1132164221@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I wonder if there should be regression tests for all the bugs exposed
> after 8.1 ... I mean, what stops anyone from introducing the same bugs
> again?

I've never been a fan of "regression tests" in the narrow sense of
"let's test for this specific mistake we made once".  If you can devise
a test that catches a class of errors including the one you actually
made, that's a different story, because it's much more likely to catch a
real future problem.

I was thinking about adding some regression tests to exercise OR-conditions
in OUTER JOIN ON clauses, because Sebastian's examples indicate that we
haven't tested that area nearly hard enough, but I'm not in favor of
just pushing his examples into the tests as-is.  (For one reason,
they'll soon stop being tests of OR-conditions at all, once I've got IN
reimplemented the way I want.)

If you want to spend some time consing up test cases, the areas I'd
suggest covering are:

1. OR clauses that actually reference both sides of the JOIN, plus
OR clauses that actually mention only the outer side or only the inner
side.

2. OR clauses consisting of AND sub-clauses where the sub-clauses are
different combinations of the above cases.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: MERGE vs REPLACE
Next
From: Bruce Momjian
Date:
Subject: Heading to Mexico