Re: Re: postgres TODO

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

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

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

			regards, tom lane