Re: RFC: Generating useful names for foreign keys and checks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Generating useful names for foreign keys and checks
Date: 2002-04-15 20:55:57
Message-ID: 26619.1018904157@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> I'm thinking of doing a patch to generate foo_fkey and foo_chk names for
> fk's and checks. I know that this will make using DROP CONSTRAINT a whole
> heck of a lot easier. There have also been a few people who've complained
> on the list about all the <unnamed> foreign keys, etc.

> I know Tom had some fears, but I don't know if they still apply, or if
> they're any worse than the current situation?

Actually I'm in favor of it. I have a proposal outstanding to require
constraints to have names that are unique per-table, for consistency
with triggers (already are that way) and rules (will become that way,
rather than having globally unique names as now). AFAIR the only
significant concern was making sure that the system wouldn't generate
duplicate constraint names by default.

Actually, I was only thinking of CHECK constraints (pg_relcheck) in this
proposal. In the long run it'd be a good idea to have a table that
explicitly lists all constraints --- check, unique, primary, foreign
key, etc --- and the index on such a table would probably enforce
name uniqueness across all types of constraints on one table. Right now,
though, each type of constraint effectively has a separate namespace.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-04-15 20:56:12 Re: [PATCHES] ANSI Compliant Inserts
Previous Message Tom Lane 2002-04-15 20:31:02 Re: Operators and schemas