From: | Jeroen Vermeulen <jtv(at)xs4all(dot)nl> |
---|---|
To: | David Kerr <dmk(at)mr-paradox(dot)net> |
Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: foreign key locks, 2nd attempt |
Date: | 2011-11-12 04:21:10 |
Message-ID: | 4EBDF436.7000004@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2011-11-12 00:30, David Kerr wrote:
> Is this being suggested in lieu of Alvaro's patch? because it seems to be adding
> complexity to the system (multiple types of primary key definitions) instead of
> just fixing an obvious problem (over-aggressive locking done on FK checks).
It wouldn't be a new type of primary key definition, just a new type of
column constraint similar to "not null." Particularly useful with keys,
but entirely orthogonal to them.
Parser and reserved words aside, it seems a relatively simple change.
Of course that's not necessarily the same as "small."
> If it's going to be in addition to, then it sounds like it'd be really nice.
I wasn't thinking that far ahead, myself. But if some existing lock
type covers the situation well enough, then that could be a big argument
for doing it in-lieu-of.
I haven't looked at lock types much so I could be wrong, but my
impression is that there are dangerously many lock types already. One
would expect the risk of subtle locking bugs to grow as the square of
the number of interacting lock types.
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-12 04:34:35 | Re: fix for psql's \dd version check |
Previous Message | Stephen Frost | 2011-11-12 01:34:40 | Re: Allow substitute allocators for PGresult. |