Re: PG Admin

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

In response to

Responses

Browse pgsql-general by date

  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?