From: | John Tregea <john(at)debraneys(dot)com> |
---|---|
To: | Scott Ribe <scott_ribe(at)killerbytes(dot)com> |
Cc: | Kenneth Downs <ken(at)secdat(dot)com>, Tim Allen <tim(at)proximity(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Return the primary key of a newly inserted row? |
Date: | 2006-06-24 00:11:08 |
Message-ID: | 449C831C.80008@debraneys.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Scott, Ken and Tim,
Thanks for the assistance, I appreciate the advice.
Scott,
The example of
select id1 = nextval(somesequence)
could work for me. I have multiple users with our GUI and imagine I
could use transaction protection to ensure no duplicates between
selecting and incrementing the somesequence...
Thanks again all.
Regards
John
Scott Ribe wrote:
>> 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;
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-24 03:27:38 | Re: VACUUM hanging on idle system |
Previous Message | Tom Lane | 2006-06-23 23:16:56 | Re: [GENERAL] Out of memory error in 8.1.0 Win32 |