Обсуждение: Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified
Tom Lane wrote: > Log Message: > ----------- > make_restrictinfo() failed to attach the specified required_relids to > its result when the clause was an OR clause. Brain fade exposed by > example from Sebastian B?ck. 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? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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
> 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. Heh. See what I do is envision a future 10 years from now when the guy who truly understands the planner and executor (Tom) has long gone and the rest of us poor buggers keep on trying to change and fix things, thereby recreating all these 10 year old bugs :) Chris
Christopher Kings-Lynne wrote: > >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. > > Heh. See what I do is envision a future 10 years from now when the guy > who truly understands the planner and executor (Tom) has long gone and > the rest of us poor buggers keep on trying to change and fix things, > thereby recreating all these 10 year old bugs :) That's why someone else should be studying the planner and executor code right now ... I've long wanted to start doing it but I've been always distracted with other minutia ... -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "PHP is what I call the "Dumb Monkey" language. [A]ny dumb monkey can code something in PHP. Python takes actual thought to produce something useful." (J. Drake)
On Wednesday 16 November 2005 21:05, Alvaro Herrera wrote:
> Christopher Kings-Lynne wrote:
> > >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.
> >
> > Heh. See what I do is envision a future 10 years from now when the guy
> > who truly understands the planner and executor (Tom) has long gone and
> > the rest of us poor buggers keep on trying to change and fix things,
> > thereby recreating all these 10 year old bugs :)
>
> That's why someone else should be studying the planner and executor code
> right now ... I've long wanted to start doing it but I've been always
> distracted with other minutia ...
If you think shared row locks and subtransactions were minutia, I think you're
the right person for the job! :-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Wed, Nov 16, 2005 at 11:05:11PM -0300, Alvaro Herrera wrote: > Christopher Kings-Lynne wrote: > > >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. > > > > Heh. See what I do is envision a future 10 years from now when the guy > > who truly understands the planner and executor (Tom) has long gone and > > the rest of us poor buggers keep on trying to change and fix things, > > thereby recreating all these 10 year old bugs :) > > That's why someone else should be studying the planner and executor code > right now ... I've long wanted to start doing it but I've been always > distracted with other minutia ... Sure, but people make mistakes. Incredibly, I think you can even find evidence of Tom making mistakes if you dig deep enough into commit logs and list archives! ;) I certainly agree that a test that will catch multiple errors is better than one that catches few (or only one), but isn't a test for a specific case better than none at all? Is the concern how long make check takes? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: >isn't a test for a specific >case better than none at all? Is the concern how long make check takes? > > It shouldn't be, since we can (and do) have multiple regression test sets. If there are tests that take too long for normal use, let's make a "takes a long time" set and a new Makefile target for it - we'll add it to the buildfarm suite so automated testing (which shouldn't care how long it takes) will do the heavy work for us. cheers andrew