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

tom and i spoke of this problem at the Open Source Database
Summit awhile back.

in a nutshell, postgres doesn't maintain explicit
relationships between tables. my experience says
that foreign/primary keys fall under the
category of extended domains, not rules, and, hence,
postgres is a bit out of the loop.

my vote is for storing the relationships in
the system tables, as most commercial DBs do.
otherwise, an entire class of DDL applications
won't be possible under postgres.

john

-

John Scott
Senior Partner
August Associates

web: http://www.august.com/~john

....................................
Get your own free email account from
http://www.popmail.com