From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Troels Arvin <troels@arvin.dk>
Cc: pgsql-sql@postgresql.org
Subject: Re: INFORMATION_SCHEMA and foreign keys
Date: Sun, 05 Sep 2004 22:13:57 -0400
Message-ID: <3724.1094436837@sss.pgh.pa.us> (raw)
In-Reply-To: <20040905162116.K38304@megazone.bigpanda.com>
References: <pan.2004.09.05.22.56.56.521040@arvin.dk>
<20040905162116.K38304@megazone.bigpanda.com>
Stephan Szabo <sszabo@megazone.bigpanda.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, sszabo@megazone.bigpanda.com, troels@arvin.dk
Subject: Re: INFORMATION_SCHEMA and foreign keys
In-Reply-To: <3724.1094436837@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox