Re: PG Admin

From: Michael Glaesemann <grzm(at)seespotcode(dot)net>
To: Bob Pawley <rjpawley(at)shaw(dot)ca>
Cc: aklaver(at)comcast(dot)net, pgsql-general(at)postgresql(dot)org, Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, Raymond O'Donnell <rod(at)iol(dot)ie>
Subject: Re: PG Admin
Date: 2006-12-05 05:07:39
Message-ID: D6B63DF0-0B71-4932-A6EA-05CE0B76B92C@seespotcode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On Dec 5, 2006, at 13:08 , Bob Pawley wrote:

> The physical devices don't get numbered until the design is
> established and stable. This is known as the construction stage.

I guess I would set up a couple of tables to track this ordering
independently of the devices themselves. Rough schema:

create table devices
(
device_id serial primary key
device_name text not null unique
);

create table plans
(
plan_id serial primary key
, plan_name text not null unique
);

create table plan_devices
(
plan_id integer not null
references plans
, device_id integer not null
references devices
, device_order serial not null
, unique (plan_id, device_id)
, unique (plan_id, device_order)
);

This idea is based around the idea that every time you make a change
to the plan, it's in essence a new plan. You insert a new plan in
plans, reset the plan_devices_device_order_seq (created by the
device_order serial column), and insert the devices for the new plan
into plan_devices in the order they should be. Of course, sequences
aren't transaction safe, but unless others are pulling from the
sequence while the new devices are being assigned to the plan, it
should be safe. You can also check the integrity of the device_order
column after the insert to make sure it's gapless.

Michael Glaesemann
grzm seespotcode net

In response to

Browse pgsql-general by date

  From Date Subject
Next Message deep ... 2006-12-05 06:42:02 Table definition changes when a row is dropped and recreated
Previous Message Guy Rouillier 2006-12-05 04:34:41 [Fwd: Re: PG Admin]