| 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: | Whole Thread | Raw Message | 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? |