Re: [GENERAL] 8.1, OID's and plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] 8.1, OID's and plpgsql
Date
Msg-id 22934.1133915083@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] 8.1, OID's and plpgsql  (Greg Stark <gsstark@mit.edu>)
Responses Re: [GENERAL] 8.1, OID's and plpgsql  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> The benefits of providing something based on ctid is to avoid the inefficiency
> of the index lookup on the primary key and it would work on tables without any
> primary key. I'm not sure it's worth the effort it would entail for those
> narrow use cases especially since I think some interface to retrieve the
> primary will still be needed anyways.

Rather than hard-wiring a special case for any of these things, I'd much
rather see us implement INSERT...RETURNING and UPDATE...RETURNING as per
previous suggestions.  Then you can fetch pkey, ctid, or whatever you
need.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [GENERAL] 8.1, OID's and plpgsql
Next
From: Greg Stark
Date:
Subject: Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)