Philip Warner <pjw@rhyme.com.au> writes:
>>> Is there a good reason why the automatically created items do not have a
>>> 'pg_' in front of their names?
>>
>> Not a good idea. I think it should probably be pk1_zzz in this case.
> That would at least be consistent, but it's still using 'user namespace'
> for system-related items, which seems like a bad practice if it can be
> avoided. I don't mind a longer name, if that is your objection:
> pg_constraint_pk1_zzz or some such.
No, my objection is that I couldn't get rid of the index with "drop index".
A pg_ prefix has semantic connotations that I think are inappropriate
for a user-table index.
As for the treading-on-user-namespace issue, we already do that for all
implicitly created indexes (see UNIQUE, PRIMARY KEY, etc). I'd prefer
to treat named constraints consistently with that long-established
practice until we have a better idea that can be implemented uniformly
across that whole set of constructs. (Once we have schemas, for
example, it might be practical to give indexes a separate namespace
from tables, which'd help a lot.)
>> uses the index name as the constraint name. I thought that patch was
>> wrongheaded anyway, and would recommend reversing it...
> I wasn't too keen on it, but could not come up with any good arguments
> against it. We need a unified approach to constraints, but in the mean time
> it seems OK. Do you have any more definite objections?
What I didn't like was the entirely unjustified assumption that a
primary key constraint *has* a name. Introducing a name where none
existed is just as bad a sin as dropping one, if not worse (which
case do you think is more common?). Given the choice between
those two evils, I'll take the one that takes less code, until such
time as we can do it right...
regards, tom lane