Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
A considerable advantage of per-relation constraint names is that a new
unique name can be assigned for a nameless constraint while holding only
a lock on the target relation. We'd need a global lock to create unique
constraint
Tom Lane writes:
A considerable advantage of per-relation constraint names is that a new
unique name can be assigned for a nameless constraint while holding only
a lock on the target relation. We'd need a global lock to create unique
constraint names in the SQL92 semantics.
Presumably, the
and not simply a lock on the pg_constraint table
In this context, a lock on pg_constraint *is* global, because it will
mean that no one else can be creating an index on some other table.
They'd need to hold that same lock to ensure that *their* chosen
constraint name is unique.
So I am
Rod Taylor [EMAIL PROTECTED] writes:
I think it would be a rare event to have more than one person changing
the database structure at the same time.
I don't buy this assumption --- consider for example two clients
creating temp tables.
Anyway, the index example is a
bad example isn't it?
SQL92 requires named constraints to have names that are unique within
their schema. Our past implementation did not require constraint names
to be unique at all; as a compromise I suggested requiring constraint
names to be unique for any given relation. Rod Taylor's pending
pg_constraint patch
One problem I see is that pg_constraint entries can *only* be associated
with relations; so the table has no way to represent constraints
associated with domains --- not to mention assertions, which aren't
associated with any table at all. I'm in no hurry to try to implement
assertions, but
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
A considerable advantage of per-relation constraint names is that a new
unique name can be assigned for a nameless constraint while holding only
a lock on the target relation. We'd need a global lock to create unique
constraint names in the
I don't buy that argument even for foreign keys --- and remember that
pg_constraint will also hold entries for CHECK, UNIQUE, and PRIMARY KEY
constraints. I don't want to have to take a global lock whenever we
create an index.
I don't understand why a global lock is necessary -- and not
Rod Taylor [EMAIL PROTECTED] writes:
I don't want to have to take a global lock whenever we
create an index.
I don't understand why a global lock is necessary --
To be sure we are creating a unique constraint name.
and not simply a lock on the pg_constraint table
In this context, a lock
One problem I see is that pg_constraint entries can *only* be associated
with relations; so the table has no way to represent constraints
associated with domains --- not to mention assertions, which aren't
It's ugly, but one could make the relid 0, and add a typeid which is
non-zero to
10 matches
Mail list logo
