"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
