Re: [HACKERS] getting new serial value of serial insert - Mailing list pgsql-hackers

From Ed Loehr
Subject Re: [HACKERS] getting new serial value of serial insert
Date
Msg-id 382098D0.80B3EA86@austin.rr.com
Whole thread Raw
In response to [HACKERS] getting new serial value of serial insert  (Ed Loehr <ELOEHR@austin.rr.com>)
Responses Re: [HACKERS] getting new serial value of serial insert  ("Aaron J. Seigo" <aaron@gtv.ca>)
List pgsql-hackers
"Aaron J. Seigo" wrote:

> >  -- this returns serial 'id' of inserted record...
> >  insert into mytable (id,name) values (0,'Mary');
>
> hm.. this is very elegant syntactically..
>
> however, it would be nice to be able to have returned any number of fields of
> any types... (for example, i have a trigger that changes a field in a record
> whenever it gets updated/inserted.. it would be nice to get this returned as
> well...)

>
> also, if possible, it would be nice to extend this to UPDATE...
>
> can you think of a way to use this syntax aproach that would meet the needs
> above?

No, and I'm not sure it'd be good to couple the two operations syntactically
even if one thought of a clever way to do it.  Serial-insert value retrieval is
a very frequent lightweight operation that fits nicely within current INSERT
syntax, and thus it seems intuitively "natural" to stretch INSERT semantics
in this way.

In the trigger scenario you mention, I'd be slightly more inclined to say it
crosses the fuzzy gray line into the area where a subsequent SELECT is in
order, as opposed to modifying INSERT syntax/semantics to allow this
SELECT functionality.  How's that for fuzzy logic?

Cheers.
Ed








pgsql-hackers by date:

Previous
From: "Aaron J. Seigo"
Date:
Subject: Re: [HACKERS] getting new serial value of serial insert
Next
From: "nicks.emails"
Date:
Subject: your commnts