RE: Table/Column Constraints

On Tue, 21 Nov 2000, Christopher Kings-Lynne wrote:

> > > Problem is that there are 5 difference types of constraints,
> > implemented in
> > > 5 different ways. Do you want a unifed, central catalog of
> > constraints, or
> > > just for some of them, or what?
> >
> > Dunno. Maybe a unified representation would make more sense, or maybe
> > it's OK to treat them separately. The existing implementations of the
> > different types of constraints were done at different times, and perhaps
> > are different "just because" rather than for any good reason. We need
> > investigation before we can come up with a reasonable proposal.
>
> It strikes me that having a catalog (so to speak) of all contraints, with
> flags in the tables where the contraints are implemented would allow a
> separation of presentation and implementation.

Yeah, the hard part is storing enough information to recover the
constraint in an easy way without going to the implementation details,
strings aren't sufficient by themselves because that gets really difficult
to maintain as table/columns change or are dropped. Maybe a central
catalog like the above and a backend function that takes care of
formatting to text would work. Or keeping track of the dependent objects
and re-figuring the text form (or drop constraint, or whatever) when those
objects are changed/dropped.

I think that combining different constraints is good to some extent
because there are alot of problems with many constraints (the RI ones have
problems, check constraints are currently not deferrable AFAIK,
the unique constraint doesn't actually have the correct semantics) and
maybe thinking about the whole set of them at the same time would be a
good idea.

> > > I assume that column contraints implicitly become table
> > constraints. This
> > > will also make it easy to have global unique contraint names.
> > Actually -
> > > are the constraint names currently unique for an entire database?
> >
> > No, and they shouldn't be --- only per-table, I think.
>
> Oops - correct. Wasn't paying attention. I forgot that the table name is
> specified as part of the ALTER statement.

I'm not sure actually, it seems to say in the syntax rules for the
constraint name definition that the qualified identifier of a constraint
needs to be different from any other qualified identifier for any other
constraint in the same schema, so Christopher may have been right the
first time (given we don't have schema).