RE: Table/Column Constraints

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Table/Column Constraints
Date: 2000-11-21 05:02:34
Message-ID: NEBBIOAJBMEENKACLNPCGEIICCAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-11-21 05:03:30 Re: Table/Column Constraints
Previous Message Philip Warner 2000-11-21 05:02:10 Re: Assert Failure with current CVS