Skip site navigation (1) Skip section navigation (2)

Re: [NOVICE] Last ID Problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "John Hansen" <john(at)geeknet(dot)com(dot)au>
Cc: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>,"Michael Fuhr" <mike(at)fuhr(dot)org>,"Mitch Pirtle" <mitch(dot)pirtle(at)gmail(dot)com>,"Tatsuo Ishii" <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org,operationsengineer1(at)yahoo(dot)com, pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] Last ID Problem
Date: 2005-02-01 16:08:27
Message-ID: 14991.1107274107@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-novice
"John Hansen" <john(at)geeknet(dot)com(dot)au> writes:
>>> Since OID's are now deprecated, and will eventually disappear, 

No one has stated that they will disappear.

>>> wouldn't it be a good idea, to have INSERT and UPDATE 
>>> return a copy of the tuple that was inserted/updated?
>> 
>> How about the TID?

> Yea, that'd work.

You could only trust it for the duration of the inserting or updating
transaction.  Which might be enough ... but changing it would certainly
break all existing apps that use this feature.

I think the correct solution is not to mess with what's admittedly a
legacy aspect of our client API.  Instead we should invent the "INSERT
RETURNING" and "UPDATE RETURNING" commands that have been discussed
repeatedly (see the pghackers archives).  That would allow people to get
what they want, and do so in only one network round trip, without any
artificial dependencies on OIDs or TIDs or anything else.  It'd be
unportable, but surely no more so than relying on OIDs or TIDs ...

			regards, tom lane

In response to

Responses

pgsql-novice by date

Next:From: Joshua D. DrakeDate: 2005-02-01 16:56:52
Subject: Re: [NOVICE] Last ID Problem
Previous:From: James DeMondDate: 2005-02-01 15:06:30
Subject: Re: Arrays of user-defined data types in other user-defined

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-01 16:15:01
Subject: Re: Group-count estimation statistics
Previous:From: Bruce MomjianDate: 2005-02-01 16:05:06
Subject: Updated FAQ

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group