> On Tue, Jan 30, 2018 at 1:21 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> About the idea: it makes some kind of sense to me that we should lock >> the underlying table, in all the same cases that you could do DML on >> the view automatically. I wonder if this is a problem for the >> soundness: "Tables appearing in a subquery are ignored and not >> locked." > > Yeah, that seems like a pretty bad idea. It's exposing what is > basically an implementation detail to users.
Initially I thought all base tables including ones in a subquery also should be locked like you. But after some discussions with Yugo, I agree that locking table in a subquery is less valuable for users (and I am afraid it may introduce more deadlock chances). See upthead discussions. > I think that if we > change the rules for which subqueries get flattened in a future > release, then the behavior will also change. That seems bad. I doubt it could happen in the future but if that happend we should disallow locking on such views. > I also think that this is a bad idea for another reason, which is that > it leaves us with no syntax to say that you want to lock the view > itself, and pg_dump wants do that if only we had syntax for it. I agree with Yugo and Alvaro. It's better to have a separate syntax for locking views itself. https://www.postgresql.org/message-id/20171226143407.6wjzjn42pt54qskm@alvherre.pgsql Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp