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

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified
Date: 2005-11-21 22:05:07
Message-ID: 20051121220506.GN19279@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message User Gsmet 2005-11-21 22:23:44 pgfouine - pgfouine: ignore common errors
Previous Message Bruce Momjian 2005-11-21 21:01:16 pgsql: Reorder "who controls PostgreSQL" to near the top.

Browse pgsql-hackers by date

  From Date Subject
Next Message Bob Ippolito 2005-11-21 22:24:21 Re: PostgreSQL 8.1.0 catalog corruption
Previous Message Tom Lane 2005-11-21 21:59:33 Re: PostgreSQL 8.1.0 catalog corruption