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

From Jim C. Nasby
Subject Re: [GENERAL] 8.1, OID's and plpgsql
Date
Msg-id 20051208071315.GN16053@nasby.net
Whole thread Raw
In response to Re: [GENERAL] 8.1, OID's and plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 07, 2005 at 12:06:23AM -0500, Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > Tom Lane <tgl@sss.pgh.pa.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...

Along those lines, I don't see anything on the TODO list about this...
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Reducing relation locking overhead
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Vertical Partitioning with TOAST