Re: [HACKERS] [PATCH] Lockable views

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Lockable views
Date: 2017-11-29 02:29:36
Message-ID: CAB7nPqQ3s+3Q8W=1EiLCmHonr=RGHfe0yEMN4JYQvY+SmhR7=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 27, 2017 at 2:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Oct 11, 2017 at 11:36 AM, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>> In the attached patch, only automatically-updatable views that do not have
>> INSTEAD OF rules or INSTEAD OF triggers are lockable. It is assumed that
>> those views definition have only one base-relation. When an auto-updatable
>> view is locked, its base relation is also locked. If the base relation is a
>> view again, base relations are processed recursively. For locking a view,
>> the view owner have to have he priviledge to lock the base relation.
>
> Why is this the right behavior?
>
> I would have expected LOCK TABLE v to lock the view and nothing else.
>
> See http://postgr.es/m/AANLkTi=KupesJHRdEvGfbT30aU_iYRO6zwK+fwwY_sGd@mail.gmail.com
> for previous discussion of this topic.

That's what I would expect as well.. But I may be missing something. I
am marking the patch as returned with feedback as this has not been
replied in one month.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-11-29 03:05:50 Re: PG10.1 autovac killed building extended stats
Previous Message Michael Paquier 2017-11-29 02:27:13 Re: [HACKERS] postgres_fdw: support parameterized foreign joins