RE: Table/Column Constraints

> > 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.

For example, say, if a catalog existed that clients could query to discover
all constraint information, then it would be possible to change how foreign
keys are implemented, and not affect how this info is presented.

However, if users still had to perform joins between some centralised table,
and the tables where the constraints are actually kept (relcheck, trigger,
etc) then that defeats the purpose. Say - isn't that what 'views' are for?

> > 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.

Chris