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: