Just to not let this die :)
> I thought about that, too, and I'd be in favor of it if it didn't have
> problems of its own. (The big one being that if the new main-table
> name is longer or shorter than the old, you would have to redo the
> whole derived-name-generation process, or run into possible truncation
> problems. So it leads to the same kind of loss of predictability I'm
> griping about.)
More arguments from me:
Why should this fail?:
User 1: CREATE TABLE a (test int4);
User 1: CREATE INDEX my_test_key ON a(test);
User 2: (blithely unaware of user1)
User 2: CREATE TABLE my (test int4, unique(test));
NOTICE: CREATE TABLE / UNIQUE will create implicit index 'my_test_key' for
table 'my'
ERROR: relation named "my_test_key" already exists
It breaks the "principle of least surprise" rule. There's no way that that
should be a total failure condition! That's a confusing error for a newbie
especially...they then have to look up the manual and see that they need to
go:
CREATE TABLE my (test int4, constraint "my_key" unique(test));
Plus they have to understand all about constraints vs. indexes, names, and
all sort of internal shenanigans that they should be insulated from. Heck,
even I get annoyed that I can't rename a table and then rerun my creation
script without it failing!!!! (As did a guy at Linux.conf.au) It's a
pretty normal way of doing large schema changes. Renaming constraint names
is an even worse idea - no way should you be renaming things for the user!
What does it mean if someone does not specify a name of a constraint? They
are saying "I don't care what name you give it, you decide for me.". In
that case, how can they possibly rely on the generated name? They won't
even know if it's going to collide or not. Anyone who needs a certain name
always has the option of specifying it explicitly.
Chris
