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
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 |