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
>> cons
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,
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 i
> > 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
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
> 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
"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 nam
> 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,
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 i
> 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 repr
10 matches
Mail list logo
