Re: python patch - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: python patch
Date
Msg-id 1029195211.41017.0.camel@jester
Whole thread Raw
In response to Re: python patch  (Greg Copeland <greg@CopelandConsulting.Net>)
Responses Re: python patch
List pgsql-hackers
All of that said, the cost of the check is so small it may save someones
ass some day when they have a corrupted catalog and the below
assumptions are no longer true.

On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
> On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > > Not a problem.  I would rather them be correct.
> > >
> > > Worth noting that the first patch is what attempts to fix the long ->
> > > int overflow issue.  The second patch attempts to resolve "attisdropped"
> > > column use issues with the python scripts.  The third patch addresses
> > > issues generated by the implicate to explicate use of "cascade".
> > >
> > > I assume your reservations are only with the second patch and not the
> > > first and third patches?
> > 
> > Correct.  I'm pretty sure you don't need to exclude attisdropped from the
> > primary key list because all it's doing is finding the column that a primary
> > key is over and that should never be over a dropped column.  I can't
> > remember what you said the second query did?
> 
> 
> Hmmm.  Sounds okay but I'm just not sure that holds true (as I
> previously stated, I'm ignorant on the topic).  Obviously I'll defer to
> you on this.
> 
> Here's the queries and what they do:
> 
> 
> >From pg.py:
> Used to locate primary keys -- or so the comment says.  It does create a
> dictionary of keys and attribute values for each returned row so I
> assume it really is attempting to do something of the like.
> 
> SELECT pg_class.relname, pg_attribute.attname 
> FROM pg_class, pg_attribute, pg_index 
> WHERE pg_class.oid = pg_attribute.attrelid AND 
>     pg_class.oid = pg_index.indrelid AND 
>     pg_index.indkey[0] = pg_attribute.attnum AND 
>     pg_index.indisprimary = 't' AND 
>     pg_attribute.attisdropped = 'f' ;
> 
> So, everyone is in agreement that any attribute which is indexed as a
> primary key will never be able to have attisdtopped = 't'?
> 
> According to the code:
> SELECT pg_attribute.attname, pg_type.typname
> FROM pg_class, pg_attribute, pg_type
> WHERE pg_class.relname = '%s' AND
>     pg_attribute.attnum > 0 AND
>     pg_attribute.attrelid = pg_class.oid AND
>     pg_attribute.atttypid = pg_type.oid AND
>     pg_attribute.attisdropped = 'f' ;
> 
> is used to obtain all attributes (column names) and their types for a
> given table ('%s').  It then attempts to build a column/type cache.  I'm
> assuming that this really does need to be there.  Please correct
> accordingly.
> 
> 
> >From syscat.py:
> SELECT bc.relname AS class_name,
>     ic.relname AS index_name, a.attname
> FROM pg_class bc, pg_class ic, pg_index i, pg_attribute a
> WHERE i.indrelid = bc.oid AND i.indexrelid = bc.oid
>     AND i.indkey[0] = a.attnum AND a.attrelid = bc.oid
>     AND i.indproc = '0'::oid AND a.attisdropped = 'f'
>     ORDER BY class_name, index_name, attname ;
> 
> According to the nearby documentation, it's supposed to be fetching a
> list of "all simple indicies".  If that's the case, is it safe to assume
> that any indexed column will never have attisdropped = 't'?  If so, we
> can remove that check from the file as well.  Worth pointing out, this
> is from syscat.py, which is sample source and not used as actual
> interface.  So, worse case, it would appear to be redundant in nature
> with no harm done.
> 
> This should conclude the patched items offered in the second patch.
> 
> What ya think?
> 
> Thanks,
>     Greg
> 
> 




pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: python patch
Next
From: Oliver Elphick
Date:
Subject: anoncvs currently broken