AW: Re: postgres TODO - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: Re: postgres TODO
Date
Msg-id 11C1E6749A55D411A9670001FA687963367FED@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> Thus spake Alessio Bragadini
> > > >       * Add function to return primary key value on INSERT
> > > 
> > > I don't get the point of this. Don't you know what you 
> inserted? For
> > > sequences there's curval()
> > 
> > Mmmhhh... it means that we can assume no update to the 
> sequence value
> > between the insert and the curval selection?
> 
> We can within one connection so this is safe but there are 
> other problems
> which I am not sure would be solved by this anyway.  With 
> rules, triggers
> and defaults there are often changes to the row between the 
> insert and the
> values that hit the backing store.  This is a general problem of which
> the primary key is only one example.
> 
> In fact, the OID of the new row is returned so what stops one 
> from just
> using it to get any information required.  This is exactly 
> what PyGreSQL
> does in its insert method.  After returning, the dictionary 
> used to store
> the fields for the row have been updated with the actual 
> contents of the
> row in the database.  It simply does a "SELECT *" using the new OID to
> get the row back.

OID access is not indexed by default, only if the dba created a
corresponding 
index. Thus OID access is a seq scan in a default environment.

Andreas


pgsql-hackers by date:

Previous
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: Re: postgres TODO
Next
From: Tom Lane
Date:
Subject: Re: Progress report: intraquery memory recovery in executor