RE: Table/Column Constraints
От | Christopher Kings-Lynne |
---|---|
Тема | RE: Table/Column Constraints |
Дата | |
Msg-id | NEBBIOAJBMEENKACLNPCGEIICCAA.chriskl@familyhealth.com.au обсуждение исходный текст |
Ответ на | Re: Table/Column Constraints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Table/Column Constraints
|
Список | 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
В списке pgsql-hackers по дате отправления: