mirror of
https://github.com/postgres/postgres.git
synced 2025-11-06 07:49:08 +03:00
Fully enforce uniqueness of constraint names.
It's been true for a long time that we expect names of table and domain constraints to be unique among the constraints of that table or domain. However, the enforcement of that has been pretty haphazard, and it missed some corner cases such as creating a CHECK constraint and then an index constraint of the same name (as per recent report from André Hänsel). Also, due to the lack of an actual unique index enforcing this, duplicates could be created through race conditions. Moreover, the code that searches pg_constraint has been quite inconsistent about how to handle duplicate names if one did occur: some places checked and threw errors if there was more than one match, while others just processed the first match they came to. To fix, create a unique index on (conrelid, contypid, conname). Since either conrelid or contypid is zero, this will separately enforce uniqueness of constraint names among constraints of any one table and any one domain. (If we ever implement SQL assertions, and put them into this catalog, more thought might be needed. But it'd be at least as reasonable to put them into a new catalog; having overloaded this one catalog with two kinds of constraints was a mistake already IMO.) This index can replace the existing non-unique index on conrelid, though we need to keep the one on contypid for query performance reasons. Having done that, we can simplify the logic in various places that either coped with duplicates or neglected to, as well as potentially improve lookup performance when searching for a constraint by name. Also, as per our usual practice, install a preliminary check so that you get something more friendly than a unique-index violation report in the case complained of by André. And teach ChooseIndexName to avoid choosing autogenerated names that would draw such a failure. While it's not possible to make such a change in the back branches, it doesn't seem quite too late to put this into v11, so do so. Discussion: https://postgr.es/m/0c1001d4428f$0942b430$1bc81c90$@webkr.de
This commit is contained in:
@@ -2004,6 +2004,30 @@ CREATE TABLE cities_partdef
|
||||
</para>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
<title>Constraint Naming</title>
|
||||
|
||||
<para>
|
||||
The SQL standard says that table and domain constraints must have names
|
||||
that are unique across the schema containing the table or domain.
|
||||
<productname>PostgreSQL</productname> is laxer: it only requires
|
||||
constraint names to be unique across the constraints attached to a
|
||||
particular table or domain. However, this extra freedom does not exist
|
||||
for index-based constraints (<literal>UNIQUE</literal>,
|
||||
<literal>PRIMARY KEY</literal>, and <literal>EXCLUDE</literal>
|
||||
constraints), because the associated index is named the same as the
|
||||
constraint, and index names must be unique across all relations within
|
||||
the same schema.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Currently, <productname>PostgreSQL</productname> does not record names
|
||||
for <literal>NOT NULL</literal> constraints at all, so they are not
|
||||
subject to the uniqueness restriction. This might change in a future
|
||||
release.
|
||||
</para>
|
||||
</refsect2>
|
||||
|
||||
<refsect2>
|
||||
<title>Inheritance</title>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user