RE: Re: postgres TODO

> -----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