On Jul 12, 2012, at 4:44, Andreas <maps(dot)on(at)gmx(dot)net> wrote:
> Am 12.07.2012 07:14, schrieb Andreas Kretschmer:
>> Marc Mamin <M(dot)Mamin(at)intershop(dot)de> wrote:
>>> A partial index would do the same, but requires less space:
>>> create unique index on log(state) WHERE state IN (0,1);
> OK, nice :)
> What if I have those states in a 3rd table?
> So I can see a state-history of when a state got set by whom.
> objects ( id serial PK, ... )
> events ( id serial PK, object_id integer FK on objects.id, ... )
> event_states ( id serial PK, event_id integer FK on events.id, state integer )
> There still should only be one event per object that has state 0 or 1.
> Though here I don't have the object-id within the event_states-table.
> Is it still possible to have a unique index that needs to span over a join of events and event_states?
No, all index columns must come from the same table. You would need to use a trigger-based system to enforce your constraint.
You can either have the triggers simply perform validation or you can create a materialized view and create the partial index on that. You could also consider creating an updatable view and avoid directly interacting with the three individual tables.
You could also just turn event states into a history table and leave the current state on the event table.
In response to
pgsql-sql by date
|Next:||From: Will Pugh||Date: 2012-07-12 16:02:03|
|Subject: How does Numeric division determine precision?|
|Previous:||From: Andreas||Date: 2012-07-12 08:44:32|
|Subject: Re: Prevent double entries ... no simple unique index|