From: | Kyle <kyle(at)actarg(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-sql(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: Getting FK relationships from information_schema |
Date: | 2004-06-08 15:13:20 |
Message-ID: | 40C5D790.6090407@actarg.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane wrote:
>Kyle <kyle(at)actarg(dot)com> writes:
>
>
>>The problem is, the constraint names ($1,
>>$2, etc.) are not unique so I don't know how to join the third query
>>into the fourth.
>>
>>
>
>Hmm, this is messy :-(. The SQL spec requires constraint names to be
>unique within a schema. Postgres doesn't require them to be unique even
>within a table.
>
I think this is only an issue when the user relies on postgres to choose
a constraint name automatically. Seems like a reasonable approach would
be to have postgres choose a name for the constraint that happens to be
unique in the schema (like tablename_fkey_$1). Then if the user wants
to make named constraints that all have the same name, he can (and
information_schema will be less useful) or he can rely on the
automatically generated names to be a bit more descriptive in
information_schema.
>Can we get away with adding
>implementation-specific columns to information_schema tables?
>If not, what other alternatives are there?
>
>
>
Another possible approach: Does the constraint name showing up in
information_schema really have to be the _real_ name? Or can we just
make a name consisting of the table name appended to the internal
postgres constraint name.
I think I like this less than the first idea.
Kyle
From | Date | Subject | |
---|---|---|---|
Next Message | Rajesh Kumar Mallah | 2004-06-08 18:41:54 | Re: Query becoming slower on adding a primary key |
Previous Message | Tom Lane | 2004-06-08 05:53:02 | Re: Getting FK relationships from information_schema |