Re: LOCK TABLE Permissions

* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> On Tue, May 12, 2015 at 4:01 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> >> On Mon, May 11, 2015 at 10:32 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> > Now for a blast from the past... This came up again on IRC recently and
> >> > reminded me that I ran into the same issue a couple years back. Updated
> >> > patch includes the refactoring suggested and includes documentation.
> >> >
> >> > Barring objections, I'll push this later today.
> >>
> >> Small suggestion: a test case in src/test/isolation?
> >
> > This is entirely a permissions-related change and src/test/isolation is
> > for testing concurrent behavior, not about testing permissions.
> >
> > I'm not saying that we shouldn't have more tests there, but it'd not
> > be appropriate for this particular patch.
>
> Perhaps. Note that we could have tests of this type though in lock.sql:
> create role foo login;
> create table aa (a int);
> grant insert on aa TO foo;
> \c postgres foo
> begin;
> insert into aa values (1);
> lock table aa in row exclusive mode; -- should pass

Yeah, it might not be bad to have tests for all the different lock types
and make sure that the permissions match up. I'd probably put those
tests into 'permissions.sql' instead though.

> Just mentioning it for the sake of the archives, I cannot work on that for now.

Ditto. I'm trying to work through the postgres_fdw UPDATE push-down
patch now..

Thanks!

Stephen