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 05:06:23 |
Message-ID: | 24871.1133931983@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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.
> I wonder whether the ui tools need anything more low level than that. In
> general sticking their grubby fingers in the query the user entered seems
> wrong and they would have to tack on a RETURNING clause.
That was mentioned before as a possible objection, but I'm not sure that
I buy it. The argument seems to be that a client-side driver would
understand the query and table structure well enough to know what to do
with a returned pkey value, but not well enough to understand how to
tack on a RETURNING clause to request that value. This seems a bit
bogus.
There may be some point in implementing a protocol-level equivalent of
RETURNING just to reduce the overhead on both sides, but I think we
ought to get the RETURNING functionality in place first and then worry
about that...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | A.j. Langereis | 2005-12-07 06:16:27 | Re: Letting a function return multiple columns instead of a single complex one |
Previous Message | Greg Stark | 2005-12-07 04:50:02 | Re: [GENERAL] 8.1, OID's and plpgsql |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Maxwell | 2005-12-07 05:09:03 | Re: Replication on the backend |
Previous Message | Greg Stark | 2005-12-07 04:50:02 | Re: [GENERAL] 8.1, OID's and plpgsql |