RE: Re: postgres TODO

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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