Thread: RFC: Generating useful names for foreign keys and checks
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
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, Pennsylvania19026
"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