Re: [HACKERS] LOCK TABLE Permissions

2015-05-12 Thread Stephen Frost
* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, May 12, 2015 at 4:53 AM, Stephen Frost wrote: > > 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

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Michael Paquier
On Tue, May 12, 2015 at 4:53 AM, Stephen Frost wrote: > 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. You mean privileges.sql, right? I just wrote a patc

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Stephen Frost
* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, May 12, 2015 at 4:01 AM, Stephen Frost wrote: > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > >> On Mon, May 11, 2015 at 10:32 PM, Stephen Frost wrote: > >> > Now for a blast from the past... This came up again on IRC rece

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Michael Paquier
On Tue, May 12, 2015 at 4:01 AM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Mon, May 11, 2015 at 10:32 PM, Stephen Frost 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 co

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Stephen Frost
All, * Stephen Frost (sfr...@snowman.net) wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > if (lockmode == AccessShareLock) > > > aclresult = pg_class_aclcheck(reloid, GetUserId(), > > > ACL_SELECT); > > > + else i

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Stephen Frost
* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Mon, May 11, 2015 at 10:32 PM, Stephen Frost 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

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Michael Paquier
On Mon, May 11, 2015 at 10:32 PM, Stephen Frost 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

Re: [HACKERS] LOCK TABLE Permissions

2015-05-11 Thread Stephen Frost
All, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > if (lockmode == AccessShareLock) > > aclresult = pg_class_aclcheck(reloid, GetUserId(), > > ACL_SELECT); > > + else if (lockmode == RowExclusiveLock) > > + aclresult =

Re: [HACKERS] LOCK TABLE Permissions

2013-07-19 Thread Robert Haas
On Fri, Jul 19, 2013 at 12:33 PM, Tom Lane wrote: > Stephen Frost writes: >> if (lockmode == AccessShareLock) >> aclresult = pg_class_aclcheck(reloid, GetUserId(), >> ACL_SELECT); >> + else if (lockmode == RowExclusiveLock) >> + aclresult

Re: [HACKERS] LOCK TABLE Permissions

2013-07-19 Thread Tom Lane
Stephen Frost writes: > if (lockmode == AccessShareLock) > aclresult = pg_class_aclcheck(reloid, GetUserId(), > ACL_SELECT); > + else if (lockmode == RowExclusiveLock) > + aclresult = pg_class_aclcheck(reloid, GetUserId(), > +

[HACKERS] LOCK TABLE Permissions

2013-07-19 Thread Stephen Frost
Greetings, We've run into a curious case and I'd like to solicit feedback regarding a possible change to the access rights required to acquire locks on a relation. Specifically, we have a process which normally INSERTs into a table and another process which Exclusive locks that same tab