> 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

Reply via email to