Re: [HACKERS] [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified

2005-11-21 Thread Jim C. Nasby
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  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified

2005-11-16 Thread Alvaro Herrera
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 Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified

2005-11-16 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified

2005-11-16 Thread Alvaro Herrera
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)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified

2005-11-16 Thread Robert Treat
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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings