Re: Table/Column Constraints

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> 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?

A join as such doesn't bother me.  For example, it'd be proper for this
hypothetical constraint catalog to have a column of table OIDs, which
you'd have to join against pg_class to get the table name from.  The
real issue is to make sure that we store enough info so that the
original table/constraint declarations can be reconstructed in a
straightforward fashion.

Peter has remarked that the SQL spec offers a set of system views
intended to provide exactly this info.  That should be looked at;
if there's a workable standard for this stuff, we oughta follow it.
        regards, tom lane