From: | Ken Corey <ken(dot)corey(at)atomic-interactive(dot)com> |
---|---|
To: | Peter Atkins <peter(dot)atkins(at)NXCD(dot)com> |
Cc: | "'pgsql-sql(at)postgresql(dot)org'" <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Returning PK of first insert for second insert use. |
Date: | 2002-07-29 20:04:30 |
Message-ID: | 1027973100.2360.278.camel@kenlinux.bithub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Mon, 2002-07-29 at 20:52, Peter Atkins wrote:
> Is there a possibility of another application accessing the DB and using the
> id before my function has completed the transaction? I'm concerned with the
> possibility of cross-over of ID's if the insert hangs.
>
> There's no way to return the id of that insert inherently, and then use it
> for the second insert? I think SQL uses something like ADD_ID, not sure.
That's the beauty of the nextval statement. The database internally
sequences requests to it so that you're kept out of harm's way.
Say process A called the function,and nextval returns 16. The function
now continues on its way, but is not finished when process B then calls
the function (before A is done), and nextval returns 17.
So, then function called by process A returns 16, and the function
called by process B returns 17.
That means that unless the results of process B depend in some way upon
the results of process A, there's no problem.
-Ken
--
Ken Corey CTO http://www.atomic-interactive.com 07720 440 731
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Atkins | 2002-07-29 20:20:01 | Re: Returning PK of first insert for second insert use. |
Previous Message | Gunther Schadow | 2002-07-29 20:00:16 | Decision support query inefficiencies ... |