From: | Erik Price <eprice(at)ptc(dot)com> |
---|---|
To: | Ericson Smith <eric(at)did-it(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: LAST_INSERT_ID equivalent |
Date: | 2003-06-12 19:17:22 |
Message-ID: | 3EE8D1C2.3080808@ptc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ericson Smith wrote:
> While many others use currval(), we tend to grab the next ID provided by
> nextval('seq') and use that to be inserted with the record. The process
> is very atomic, and the ID is available to be used by the rest of your
> program. The only drawback is if your insert query fails there will be a
> hole in the sequence.
So you're saying that you perform a pre-query to fetch the nextval, then
you include that in your query where you perform the INSERT? I see.
Since this is all part of the same transaction, the nextval value won't
overwrite another simultaneous INSERT, I assume. This seems like a good
way to do it too. I don't mind the holes in the sequence, but wouldn't
this INSERT cause the sequence to increment the primary key yet again?
Erik
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2003-06-12 19:19:49 | Re: need a method to ping a running database |
Previous Message | Clay Luther | 2003-06-12 18:54:44 | Choosing Between PL/PGSQL or C/C++ for Triggers/Store Procs |