From: | "Dan Langille" <dan(at)langille(dot)org> |
---|---|
To: | "Joel Burton" <joel(at)joelburton(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: SERIAL Field |
Date: | 2002-05-06 16:41:24 |
Message-ID: | 20010507124341.00EE03F43@bast.unixathome.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 6 May 2002 at 10:51, Joel Burton wrote:
> > But the very idea of inserting the value and then retriving the sequence
> > number sounds fishy to me. Why not get the sequence number first and than
> > insert using that seqnce number (more on the flash tutorial ).
That's pretty standard in a number of database applications (i.e. not just
PostgreSQL situations).
> Hmmm... does nextval() 'hold' a sequence number for this backend?
> Otherwise, the risk would be that you request a value, and someone else has
> beat you to it before you insert it.
I use nextval all the time. In fact:
fp2migration=# \d users
Column | Type | Modifiers
------------+--------------------------+--------------------------
id | integer | not null default nextval('users_id_seq'::text)
What's wrong this this? Nobody is going to "beat me to it".
> In any event, inserting then using currval() is the standard practice
> around here, and it works great. Nothing fishy at all here, nothing to see,
> move on.
Why is that "less risk"?
--
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/ - practical examples
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Burton | 2002-05-06 16:43:24 | Re: SERIAL Field |
Previous Message | Joel Burton | 2002-05-06 14:57:19 | Re: SERIAL Field |