Re: python patch - Mailing list pgsql-hackers

Yep - alright, just commit it I guess.

Chris

> -----Original Message-----
> From: Greg Copeland [mailto:greg@copelandconsulting.net]
> Sent: Thursday, 15 August 2002 11:09 AM
> To: Rod Taylor
> Cc: Christopher Kings-Lynne; Bruce Momjian; PostgresSQL Hackers Mailing
> List
> Subject: Re: [HACKERS] python patch
>
>
> Well, I tend to agree with that.  Overall, I can't say that I see bad
> things coming out of accepting the patch as is.  It's not exactly
> causing an extra join or other wise a significant waste of resources.
> At worst, it appears to be ambiguous.  Since Christopher has not offered
> any additional follow up, can we assume that he agrees?  In not, please
> let me know and I'll resubmit patch #2.
>
> In the mean time, patches #1 and #3 should be good to go.  Bruce, feel
> free to apply those whenever time allows.
>
> Thanks,
>     Greg Copeland
>
>
> On Mon, 2002-08-12 at 18:33, Rod Taylor wrote:
> > 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
> > >
> > >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>