From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Bob Pawley" <rjpawley(at)shaw(dot)ca> |
Cc: | "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com>, "Raymond O'Donnell" <rod(at)iol(dot)ie>, "pgsql general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PG Admin |
Date: | 2006-12-13 14:04:52 |
Message-ID: | b42b73150612130604v1470799bv65e2f437921f018@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/4/06, Bob Pawley <rjpawley(at)shaw(dot)ca> wrote:
> Your missing the point.
>
> I am creating a design system for industrial control.
>
> The control devices need to be numbered. The numbers need to be sequential.
> If the user deletes a device the numbers need to regenerate to again become
> sequential and gapless.
if that's the case then you need to simply renumber the tables after
deletion. serial column is ok. method is after record deletion:
1. acquire lock to prevent race (use advisory lock or some other lock,
table for example)
2. reset sequence to initial state (read setval in docs)
3. update foo set col=nextval('s')
4. release lock
this may be done on trigger if necesary. if using advisory lock, make
sure to catch sql exception and release lock just in case.
records will be renumberd and sequence will be pointed at next
allocation slot. if your design can accomidate short term gaps in the
sequence, simply keep a freelist table maintained by a trigger upon
record deletions and check that first before grabbing sequence.
also, do not even cotemplate using this column as primary key (use
unique constraint).
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Filip Rembiałkowski | 2006-12-13 14:19:45 | error messages without schema name |
Previous Message | Ron Johnson | 2006-12-13 13:59:19 | Re: Why DISTINCT ... DESC is slow? |