Re: Scope of constraint names

Rod Taylor <rbt@zort.ca> writes:
> bad example isn't it?  It already takes an lock on pg_class which is
> just as global.
>> 
>> Au contraire; there is no exclusive lock needed at present.

> Oh..  I thought pg_class was locked for any relation creation.

We only take a standard writer's lock (RowExclusiveLock) on system
catalogs that we modify.  This is mainly to avoid problems from
a concurrent VACUUM FULL moving tuples around --- it doesn't prevent
other processes from inserting/updating/deleting other rows in the
same catalog.

Most of the interesting locking done for DDL operations is done on
the relation being defined or modified, not on the system catalogs.
So we have full concurrency in terms of being able to do DDL operations
on different relations at the same time.  That's what I don't want to
give up.


If we want to go over to SQL-spec-compatible naming of constraints
(ie, unique within schemas), I think the only way to cope is to generate
unique names for nameless constraints using the OID counter --- so
they'd really be, say, "$8458321" --- but when reporting constraint
violation errors, substitute "<unnamed>" or some other fixed string
in the error report for any constraint having a name of this form.
Doing the latter would keep the regression test expected outputs stable.
Using the OID counter (or a sequence generator) would avoid the locking
problem.

Another thing we need to think about in any case is coping with
constraints that are inherited from a parent table or from a domain
that's used as one or more columns' datatype.  Whether we think
constraints should have per-schema or per-relation names, we lose
anyway if we make multiple copies of such a constraint.

Perhaps we need to distinguish "original" constraints (which could
reasonably be expected to have schema-wide-unique names) from "derived"
constraints, which are the check expressions we actually attach to
individual columns.  I think we'd want to store the derived versions
explicitly (eg, with column numbers in Vars adjusted to match the
column that's supposed to be tested in a given table), but they'd not
be expected to have unique names.  This leads to the idea that a
pg_constraint entry needs two name fields: its real name, which is
unique but might just be an autogenerated "$nnn", and its logical name
that we actually report in constraint violation messages.  The logical
name would be inherited from the "original" constraint when building
a "derived" constraint.  We'd also set up pg_depend dependencies to
link the derived constraints to their original.  This would be needed
to make ALTER DOMAIN DROP CONSTRAINT work.

Thoughts anyone?
        regards, tom lane