> On Tue, Jan 30, 2018 at 1:21 AM, Thomas Munro
> <thomas.munro@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
