Re: [HACKERS] Another bug in pg_operator.h - Mailing list pgsql-hackers

> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > This was, um, fruitful.
> 
> My *goodness*, that was a good idea.
> 
> I have now located and repaired ninety-three distinct bugs in
> pg_operator.h, all of the form "operator A has an incorrect com, negate,
> or sort link to operator B".  Almost none of them required any semantic
> analysis to spot --- I found them by looking for conditions like A links
> to B but B doesn't link to A, or A claims B is its commutation but B
> doesn't have the right input data types to be that, etc.

Green light.  Go.

> 
> The tinterval regress test now produces believable results --- ie,
> the order in which allegedly-sorted intervals appear actually agrees
> with the length of the intervals.  I would imagine that we can get
> rid of the special-case NetBSD expected output for tinterval, as well.
> 
> I will shortly commit these changes (as soon as I finish another
> build/regress pass).  I will also commit a new regression test script
> that looks for all the test conditions that I used to locate these
> problems, in hopes that no new bugs of this ilk will creep in.

What I did was to make a file in the include/catalog directory called
template1_check.sql and pg_attribute_check.sql.  These are SQL
statements that check various catalogs and report problems where things
are missing joins.  Perhaps we could put something in there, or move
these to the regression directory and include them in your stuff.  They
are not platform-specific.

Would be nice so we could spot the problems right away.  Or perhaps put
a script in include/catalogs that checks all the system tables, and run
that from the regression directory.  That would be nice too.

> 
> There is one unfixed bug in pg_operator, which I let go because I didn't
> want to make the decision as to what to do with it, but it needs to be
> fixed.  Namely, there is a conflict between OIDs 512 (on_ppath) and 754
> (pt_contained_path), both of which claim to be the implementation of
> "point @ path":
> 
> DATA(insert OID = 512 (  "@"       PGUID 0 b t f 600 602  16   0   0   0   0 on_ppath intltsel intltjoinsel ));
> 
> DATA(insert OID = 754 (  "@"       PGUID 0 b t f  600  602     16  755  0 0 0 pt_contained_path - - ));


I see "@" means "on" sometimes, and "contained" sometimes, and they use
"@" for both uses for the point/path combination.  Looks like a problem
that "@" applies to point/path, and "on" and "contained" are both valid.
However, they seem to mean the same thing.  Are on_ppath and
pt_contained_path doing the same thing.  Thomas could help here.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026