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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
