From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | nagata(at)sraoss(dot)co(dot)jp |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] [PATCH] Lockable views |
Date: | 2017-12-28 00:29:11 |
Message-ID: | 20171228.092911.1680395468831611992.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I didn't want to change the interface of view_query_is_auto_updatable()
> because this might be called from other third-patry software, so I renamed
> this function to view_query_is_auto_updatable_or_lockable() and added the flag
> to this. I created view_query_is_auto_updatable() as a wrapper of this function.
> I also made view_query_is_lockable() that returns a other message than
> view_query_is_auto_updatable().
>
>> On Tue, 17 Oct 2017 11:59:05 +0900 (JST)
>> Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
>> > 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.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-12-28 00:47:52 | Re: [HACKERS] taking stdbool.h into use |
Previous Message | Tom Lane | 2017-12-27 23:20:49 | Re: Reproducible builds: genbki.pl and Gen_fmgrtab.pl |