Re: python patch - Mailing list pgsql-hackers

OK, I have applied all three of Greg's python patches.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:
> 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
> >
> >
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073