"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
