From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>, Alessio Bragadini <alessio(at)albourne(dot)com> |
Subject: | AW: Re: postgres TODO |
Date: | 2000-07-10 13:58:08 |
Message-ID: | 11C1E6749A55D411A9670001FA687963367FED@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2000-07-10 14:03:54 | Re: Re: [GENERAL] PostgreSQL vs. MySQL |
Previous Message | D'Arcy J.M. Cain | 2000-07-10 13:52:21 | Re: Re: postgres TODO |