Re: operator exclusion constraints

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints
Date: 2009-11-18 14:21:43
Message-ID: 4B0402F7.3090105@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All,

FWIW, I'm doing a redesign of a client's production web application
right now. I was able, by combining OEC and the Period type from
pgfoundry, to make a set of constraints for declaratively asserting in a
sports database:

That the same player couldn't belong to two different teams at the same
time;
That the same player couldn't belong to the same team in two different
positions with overlapping time periods.

This worked as spec'd, and would be extremely useful for this real-world
app if it was ready to use in production now.

However, I do have an issue with the SQLSTATE returned from the OEC
violation. Currently it returns constraint violation, which, from the
perspective of an application developer, is not useful. OECs are, in
application terms, materially identical to UNIQUE constraints and serve
the same purpose. As such, I'd far rather see OECs return unique key
violation instead, as any existing application error-trapping code would
handle the violation more intelligently if it did.

--Josh Berkus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2009-11-18 14:47:11 Re: Very bad FTS performance with the Polish config
Previous Message Dimitri Fontaine 2009-11-18 14:14:24 Re: operator exclusion constraints