Обсуждение: pgsql-server: Clean up generation of default names for constraints,

Log Message:
-----------
Clean up generation of default names for constraints, indexes, and serial
sequences, as per recent discussion.  All these names are now of the
form table_column_type, with digits added if needed to make them unique.
Default constraint names are chosen to be unique across their whole schema,
not just within the parent object, so as to be more SQL-spec-compatible
and make the information schema views more useful.

Modified Files:
--------------
    pgsql-server/src/backend/catalog:
        heap.c (r1.269 -> r1.270)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/catalog/heap.c.diff?r1=1.269&r2=1.270)
        pg_constraint.c (r1.19 -> r1.20)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/catalog/pg_constraint.c.diff?r1=1.19&r2=1.20)
    pgsql-server/src/backend/commands:
        indexcmds.c (r1.120 -> r1.121)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/indexcmds.c.diff?r1=1.120&r2=1.121)
        tablecmds.c (r1.112 -> r1.113)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/tablecmds.c.diff?r1=1.112&r2=1.113)
        typecmds.c (r1.58 -> r1.59)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/commands/typecmds.c.diff?r1=1.58&r2=1.59)
    pgsql-server/src/backend/parser:
        analyze.c (r1.304 -> r1.305)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/parser/analyze.c.diff?r1=1.304&r2=1.305)
    pgsql-server/src/include/catalog:
        pg_constraint.h (r1.10 -> r1.11)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/catalog/pg_constraint.h.diff?r1=1.10&r2=1.11)
    pgsql-server/src/include/commands:
        defrem.h (r1.56 -> r1.57)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/commands/defrem.h.diff?r1=1.56&r2=1.57)
    pgsql-server/src/include/parser:
        analyze.h (r1.26 -> r1.27)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/parser/analyze.h.diff?r1=1.26&r2=1.27)
    pgsql-server/src/test/regress/expected:
        alter_table.out (r1.83 -> r1.84)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/alter_table.out.diff?r1=1.83&r2=1.84)
        cluster.out (r1.15 -> r1.16)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/cluster.out.diff?r1=1.15&r2=1.16)
        copy2.out (r1.18 -> r1.19)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/copy2.out.diff?r1=1.18&r2=1.19)
        domain.out (r1.30 -> r1.31)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/domain.out.diff?r1=1.30&r2=1.31)
        foreign_key.out (r1.34 -> r1.35)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/foreign_key.out.diff?r1=1.34&r2=1.35)
        namespace.out (r1.1 -> r1.2)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/namespace.out.diff?r1=1.1&r2=1.2)
        rules.out (r1.88 -> r1.89)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/rules.out.diff?r1=1.88&r2=1.89)
        sequence.out (r1.5 -> r1.6)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/sequence.out.diff?r1=1.5&r2=1.6)
        truncate.out (r1.8 -> r1.9)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/truncate.out.diff?r1=1.8&r2=1.9)
    pgsql-server/src/test/regress/output:
        constraints.source (r1.39 -> r1.40)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/output/constraints.source.diff?r1=1.39&r2=1.40)
    pgsql-server/src/test/regress/sql:
        copy2.sql (r1.9 -> r1.10)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/sql/copy2.sql.diff?r1=1.9&r2=1.10)

> Clean up generation of default names for constraints, indexes, and serial
> sequences, as per recent discussion.  All these names are now of the
> form table_column_type, with digits added if needed to make them unique.
> Default constraint names are chosen to be unique across their whole schema,
> not just within the parent object, so as to be more SQL-spec-compatible
> and make the information schema views more useful.

Do you do any sort of 'locking of potential names' to ensure that
another process adding a sequence at the same time or something won't
get the same name first, causing yours to still fail or break uniqueness?

Or do we just not care since it's unlikely to happen and our transation
would likely have some exclusive lock anyway?

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> Clean up generation of default names for constraints, indexes, and serial
>> sequences, as per recent discussion.

> Do you do any sort of 'locking of potential names' to ensure that
> another process adding a sequence at the same time or something won't
> get the same name first, causing yours to still fail or break uniqueness?

It's not 100% bulletproof, but I'd say that in practice I don't expect
any problems.  For instance, since all the generated names start with
the base relation name, in the absence of truncation there can't be any
such conflict --- ALTER TABLE will be holding an exclusive lock on the
base relation, and in the CREATE TABLE case you're going to die on the
base relation name conflict anyway.

If you use sufficiently long table/field names then different tables
could truncate to the same generated names, and in that case there's
some risk of concurrently choosing the same "unique" name.  But I don't
recall anyone having complained of that since we started using this
technique for choosing index names, so I'm not very worried.  Basically
what this commit did was propagate the index naming technique to
constraints and sequences.

            regards, tom lane