Re: PostgreSQL roadmap for 8.2 and beyond. - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: PostgreSQL roadmap for 8.2 and beyond.
Date
Msg-id 06ACAA35-9274-445B-8612-1A0AC95187EA@fastcrypt.com
Whole thread Raw
In response to Re: PostgreSQL roadmap for 8.2 and beyond.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostgreSQL roadmap for 8.2 and beyond.
Re: PostgreSQL roadmap for 8.2 and beyond.
List pgsql-hackers
On 17-Oct-05, at 12:43 PM, Tom Lane wrote:

> Martijn van Oosterhout <kleptog@svana.org> writes:
>
>> On Mon, Oct 17, 2005 at 09:12:35AM -0400, Dave Cramer wrote:
>>
>>> AFAIKS, the protocol needs to be tweaked to return at a minimum the
>>> currval for the first serial in the row, but more correctly all of
>>> the modified currval's  for an insert
>>>
>
>
>> In what sense? It seems to do exactly what you want. The example  
>> in the
>> documentation is:
>>
>
>
>> INSERT INTO films (title) VALUES ('Yojimbo') RETURNING film_id;
>>
>
> What Dave wants is for INSERT to automagically return any  
> autogenerated
> keys, *without* any explicit RETURNING clause.
>
Yes, this is the essence of what would be required.
> I don't think that's a reasonable request, however: it amounts to a
> request to break the protocol and impose possibly-useless overhead on
> everyone's inserts, in order to save the JDBC driver some work in
> analyzing table metadata.

The JDBC problem at hand is there is a method which allows one to  
retrieve the
autogenerated keys from an insert. I can understand Tom's argument  
here. It should
be possible for the driver to build a query from the meta data.

On the other hand given that all of the serial increments are stored  
in the session is it possible to
get the results of the last insert on the session ? If we can avoid  
the extra query so much
the better, but either way is better than what we have ?

Dave
>
>             regards, tom lane
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that  
> your
>        message can get through to the mailing list cleanly
>
>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq's pollution of application namespace
Next
From: Tom Lane
Date:
Subject: Re: libpq's pollution of application namespace