From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Chris <cmattmiller(at)gmail(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Creating a sequence |
Date: | 2008-04-23 17:00:51 |
Message-ID: | 480F6B43.8080407@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Chris wrote:
> That was my problem, I didn't know where or how to create the sequence.
> Got it to work now. :D
> So, should the standard practice be to create a sequence for every table?
That leads in to the synthetic vs natural primary key debate, which
isn't worth getting into here.
If you have a synthetic key on a table (a "meaningless" integer
identifier generated by the application or database) then a sequence is
an extremely good way of generating such identifiers. The use of a
sequence permits multiple concurrent inserts without risk of conflict
and without the need for locking.
You *WILL* get gaps in your primary key values, though, where
transactions have rolled back. Your application should be designed not
to care about this.
By the way, I pointed out the stupid way of setting a sequence start
value. What I should've written was:
CREATE SEQUENCE employee_emp_uid_seq;
SELECT setval('employee_emp_uid_seq',
(SELECT max(emp_uid) FROM employee));
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Olaf Tomczak | 2008-04-23 19:28:57 | Re: Query parameters limit in postgres jdbc driver? |
Previous Message | Chris | 2008-04-23 16:01:42 | Login Roles |