| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [GENERAL] 8.1, OID's and plpgsql |
| Date: | 2005-12-07 00:24:43 |
| Message-ID: | 22934.1133915083@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | Postg토토 캔SQL : pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-12-07 04:28:19 | Re: ltree patch is available |
| Previous Message | Greg Stark | 2005-12-07 00:18:15 | Re: [GENERAL] 8.1, OID's and plpgsql |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2005-12-07 00:32:30 | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead) |
| Previous Message | Greg Stark | 2005-12-07 00:18:15 | Re: [GENERAL] 8.1, OID's and plpgsql |