| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
| Cc: | Troels Arvin <troels(at)arvin(dot)dk>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: INFORMATION_SCHEMA and foreign keys |
| Date: | 2004-09-06 02:13:57 |
| Message-ID: | 3724.1094436837@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Mon, 6 Sep 2004, Troels Arvin wrote:
>> Is my only way forward to drop using the INFORMATION_SCHEMA and work with
>> the pg_catalog if I want to determine which columns are being referred to
>> in a (set of) foreign key column(s)?
> Possibly, yes. You'd be better off if you named your constraints rather
> than letting the system name them for you, but in general you can't rely
> on someone else doing that. This is a side effect of allowing table
> unique constraint names rather than schema unique constraint names (as a
> side note you would need to constrain schema in those joins even if we
> did schema unique names).
FWIW, the default constraint name creation rules have been rejiggered in
8.0 so that it's much more likely that generated names will be unique
schema-wide (see ChooseConstraintName). But we do not make any attempt
to positively guarantee this --- in particular, the user can still pick
nonunique constraint names, and databases reloaded from existing dumps
are likely to still have lots of "$1" etc.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel M. | 2004-09-06 03:42:47 | Storing properties in a logical way. |
| Previous Message | Stephan Szabo | 2004-09-05 23:29:58 | Re: INFORMATION_SCHEMA and foreign keys |