>> >> > 1) Leave as it is (ignore tables appearing in a subquery) >> >> > >> >> > 2) Lock all tables including in a subquery >> >> > >> >> > 3) Check subquery in the view >> > >> >> > So it seem #1 is the most reasonable way to deal with the problem >> >> > assuming that it's user's responsibility to take appropriate locks on >> >> > the tables in the subquery. >> > >> > I adopted #1 and I didn't change anything about this. >> >> Looks good to me except that the patch lacks documents and the >> regression test needs more cases. For example, it needs a test for the >> case #1 above: probably using pg_locks to make sure that the tables >> appearing in the subquery do not hold locks. > > Attached is the update patch, v3. I add some regression test and > the documentation.
The patch produces a warning. /home/t-ishii/lock_view-v3.patch:542: trailing whitespace. -- Verify that we can lock a auto-updatable views warning: 1 line adds whitespace errors. Your addition to the doc: + Automatically updatable views (see <xref linkend="sql-createview">) + that do not have <literal>INSTEAD OF</> triggers or <literal>INSTEAD</> + rules are also lockable. When a view is locked, its base relations are + also locked recursively with the same lock mode. does not mention about the point: >> >> > 1) Leave as it is (ignore tables appearing in a subquery) Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
