RFC: Generating useful names for foreign keys and checks

Yes! Please do something with those unnamed constraints.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:

Hi,

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?

Can I go ahead?

Chris

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"Christopher Kings-Lynne" <chriskl@familyhealth.com.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

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.

Yeah, that's what's giving me pain - foreign key names are generated in the
rewriter or something somewhere, so I'm not sure exactly what I have access
to for checking duplicates...

The other interesting issue is the the little suffix we append is just in
the name. ie. someone can create an index called '_pkey' and cause
confusion.

Chris