> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > I've forgotten to propose that INSERT returns TID together
> > with OID before 7.0. This has been in my mind since
> > I planned to implement Tid scan. Different from OID
> > ,TID has its specific (fast) access method now.
>
> Couple of thoughts here ---
>
> * OID is (nominally) unique across tables. TID is not. This is a
> serious point in the presence of inheritance. I'd like to see the
> return be table OID plus TID if we are going to rely on TID.
>
> * TID identification of a row does not survive VACUUM, does it?
> So you'd have to assume a vacuum didn't happen in between. Seems a
> little risky. Vadim's overwriting smgr would make this issue a lot
> worse. Might be OK in certain application contexts, but I wouldn't
> want to encourage people to use it without thinking.
>
VACUUM would invalidate keeped TIDs. Even OIDs couldn't
survive 'drop and create table'.
So I would keep [relid],oid,tid-s for fetched rows and reload
the rows using tids (and [relid]). If the OID != keeped OID,then
I would refresh the resultset entirely.
BTW,wouldn't TIDs be more stable under overwriting smgr ?
Unfortunately TIDs are transient under current no overwrite
smgr and need to follow update chain of tuples.
> * I don't see any way to add TID (or table OID) to the default return
> data without changing the fe/be protocol and breaking a lot of existing
> client code.
>
I've thought backends could return info 'INSERT oid count tid'
to their frontends but is it imposiible ?
Should (tuples)count be the 3rd and the last item to return on INSERT ?
> Philip's INSERT ... RETURNING idea could support returning TID and
> table OID as a special case, and it has the saving grace that it
> won't affect apps that don't use it...
>
If commandInfo(cmdStatus) is unavailable,this seems to be
needed though I don't know how to implement it.
Regards.
Hiroshi Inoue
