From: | Ed Loehr <ELOEHR(at)austin(dot)rr(dot)com> |
---|---|
To: | "Aaron J(dot) Seigo" <aaron(at)gtv(dot)ca> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] getting new serial value of serial insert |
Date: | 1999-11-03 20:19:28 |
Message-ID: | 382098D0.80B3EA86@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron J. Seigo | 1999-11-03 23:15:15 | Re: [HACKERS] getting new serial value of serial insert |
Previous Message | Aaron J. Seigo | 1999-11-03 20:16:13 | Re: [HACKERS] getting new serial value of serial insert |