Jeff Davis <pg...@j-davis.com> writes:
> It could go something like this (syntax still open for discussion, for
> illustration only):
> EXCLUSION (room CHECK WITH =,
> attendee CHECK WITH =,
> during CHECK WITH &&)
> CARDINALITY 30
There's an old design principle that says "the only good numbers in
computer science are 0, 1, and N" -- that is, if you need to allow more
than one of something, you should have no hard-wired upper bound on
how many of them you allow. The reason that meme comes to mind is that
I'm having difficulty seeing applications for this type of constraint.
I can certainly believe that people might like to enforce constraints
like "no more than N people are signed up for class X". The problem is
that they won't want the *same* N for every class, and that's what this
constraint design seems to require. What they'll want is N drawn from
some other table entry about the size of the classroom. If you can't
support that then the design isn't fully baked yet.
(Of course, the reason UNIQUE constraints are good is that they
correspond to the number 1 ;-))
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
