Re: [GENERAL] 8.1, OID's and plpgsql

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, "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-08 07:13:15
Message-ID: 20051208071315.GN16053@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Dec 07, 2005 at 12:06:23AM -0500, Tom Lane wrote:
> 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...

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message hubert depesz lubaczewski 2005-12-08 08:20:09 Re: tables with lots of columns - what alternative from performance point of view?
Previous Message Tom Lane 2005-12-08 04:38:53 Re: Memory Leakage Problem

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-12-08 07:34:23 Re: Vertical Partitioning with TOAST
Previous Message Jim C. Nasby 2005-12-08 07:08:10 Re: Reducing relation locking overhead