> 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.
That would then require that an optional oid be stored that relates the
constraint to a particular attribute in a table, not just the table itself.
That way, column restraints can be reconstructed.
> 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.
Speaking of - I simply cannot find a standard SQL specification anywhere on
the net, without buying one from ANSI. I'm forced to rely on
vendor-specific docs - which are not standard in any way. Is anyone able to
mail me such a thing?
Chris