From: | Scott Ribe <scott_ribe(at)killerbytes(dot)com> |
---|---|
To: | Kenneth Downs <ken(at)secdat(dot)com>, Tim Allen <tim(at)proximity(dot)com(dot)au> |
Cc: | John Tregea <john(at)debraneys(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Return the primary key of a newly inserted row? |
Date: | 2006-06-23 15:09:23 |
Message-ID: | C0C16043.4DE06%scott_ribe@killerbytes.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> SQL Server had a nifty feature here. You could simply toss a SELECT
> statement at the end of a trigger of sproc and the results would be
> returned.
>
> This in effect made a table the potential return type of all commands,
> which could be exploited very powerfully.
>
> Do the hackers have any thoughts along those lines?
It's also a "for instance" where inline creation of variables is useful. As
in:
select id1 = nextval(somesequence)
insert into tbl (id...) values (id1...)
select id2 = nextval(somesequence)
insert into tbl (id...) values (id2...)
select id3 = nextval(somesequence)
insert into tbl (id...) values (id3...)
select id1, id2, id3;
Or returning multiple result sets...
insert into tbl (id...) values (nextval(somesequence)...) returning new.id;
insert into tbl (id...) values (nextval(somesequence)...) returning new.id;
insert into tbl (id...) values (nextval(somesequence)...) returning new.id;
--
Scott Ribe
scott_ribe(at)killerbytes(dot)com
http://www.killerbytes.com/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-23 15:57:13 | Re: Documentation of the Front End/Back End Protocol for Large Objects |
Previous Message | Martijn van Oosterhout | 2006-06-23 14:06:13 | Re: Plperl and my() lexical variables bug? |