On Wed, Feb 03, 2016 at 01:44:28PM -0500, Robert Haas wrote:
> On Thu, Jan 28, 2016 at 4:37 PM, Stephen Frost wrote:
> > pg_monitor
> >
> > Allows roles granted more information from pg_stat_activity. Can't be
> > just a regular non-default-role right as we don't, currently, have a
> > way
On Thu, Jan 28, 2016 at 4:37 PM, Stephen Frost wrote:
> pg_monitor
>
> Allows roles granted more information from pg_stat_activity. Can't be
> just a regular non-default-role right as we don't, currently, have a
> way to say "filter out the values of certain columns on certain rows,
> but
On Sun, Jan 31, 2016 at 7:55 AM, Michael Paquier
wrote:
> On Sun, Jan 31, 2016 at 5:32 AM, Craig Ringer wrote:
>> On 29 January 2016 at 22:41, Stephen Frost wrote:
>>>
>>> Michael,
>>>
>>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> > On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost
On Sun, Jan 31, 2016 at 5:32 AM, Craig Ringer wrote:
> On 29 January 2016 at 22:41, Stephen Frost wrote:
>>
>> Michael,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> > On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost
>> > wrote:
>> > > * Robert Haas (robertmh...@gmail.com) wrote:
>
On 29 January 2016 at 22:41, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost
> wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
> > >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> > wrote:
On Fri, Jan 29, 2016 at 11:41 PM, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
>> wrote:
>>
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
> wrote:
> >> > Personally, I don't have any particular issue having both, b
On Fri, Jan 29, 2016 at 6:37 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost
wrote:
>> > Personally, I don't have any particular issue having both, but the
>> > desire was stated that it would be better to have the regular
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost wrote:
> >> So, this seems like a case where a built-in role would be
> >> well-justified. I don't really believe in built-in roles as a way of
> >> bundling related permissions; I know you do, but I do
On Thu, Jan 28, 2016 at 11:04 AM, Stephen Frost wrote:
>> So, this seems like a case where a built-in role would be
>> well-justified. I don't really believe in built-in roles as a way of
>> bundling related permissions; I know you do, but I don't. I'd rather
>> see the individual function permi
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost wrote:
> > I'm not against that idea, though I continue to feel that there are
> > common sets of privileges which backup tools could leverage.
> >
> > The other issue that I'm running into, again, while
On 1/17/16 9:10 PM, Stephen Frost wrote:
> but if it's possible to do a backup without
> being a superuser and with only read access to the data directory, I
> would expect every backup soltuion to view that as a feature which they
> want to support, as there are environments which will find it des
On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost wrote:
> I'm not against that idea, though I continue to feel that there are
> common sets of privileges which backup tools could leverage.
>
> The other issue that I'm running into, again, while considering how to
> move back to ACL-based permissions
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 09:23:14PM -0500, Stephen Frost wrote:
> > > > Group ownership and permissions aren't a backup-method-specific
> > > > requirement either, in my view. I'm happy to chat with Marco (who has
> > > > said he would be weighing in on t
On Sun, Jan 17, 2016 at 09:23:14PM -0500, Stephen Frost wrote:
> > > Group ownership and permissions aren't a backup-method-specific
> > > requirement either, in my view. I'm happy to chat with Marco (who has
> > > said he would be weighing in on this thread when he is able to)
> > > regarding bar
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 09:10:23PM -0500, Stephen Frost wrote:
> > > While the group owner of the directory is a distributions question, the
> > > permissions are usually a backup-method-specific requirement. I can see
> > > us creating an SQL function t
On Sun, Jan 17, 2016 at 09:10:23PM -0500, Stephen Frost wrote:
> > While the group owner of the directory is a distributions question, the
> > permissions are usually a backup-method-specific requirement. I can see
> > us creating an SQL function that opens up group permissions on the data
> > dir
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 06:58:25PM -0500, Stephen Frost wrote:
> > I'm not against that idea, though I continue to feel that there are
> > common sets of privileges which backup tools could leverage.
> >
> > The other issue that I'm running into, again,
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote:
> > Right, we also check in the backend on startup for certain permissions.
> > I don't recall offhand if that's forced to 700 or if we allow 750.
> >
> > > > I don't recall offhand i
On Sun, Jan 17, 2016 at 06:58:25PM -0500, Stephen Frost wrote:
> I'm not against that idea, though I continue to feel that there are
> common sets of privileges which backup tools could leverage.
>
> The other issue that I'm running into, again, while considering how to
> move back to ACL-based pe
On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote:
> Right, we also check in the backend on startup for certain permissions.
> I don't recall offhand if that's forced to 700 or if we allow 750.
>
> > > I don't recall offhand if that means we'd have to make changes to allow
> > > that,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Jan 6, 2016 at 12:29:14PM -0500, Robert Haas wrote:
> > The point is that with the GRANT EXECUTE ON FUNCTION proposal, authors
> > of monitoring tools enjoy various really noteworthy advantages. They
> > can have monitoring roles which have *exa
On Wed, Jan 6, 2016 at 12:29:14PM -0500, Robert Haas wrote:
> The point is that with the GRANT EXECUTE ON FUNCTION proposal, authors
> of monitoring tools enjoy various really noteworthy advantages. They
> can have monitoring roles which have *exactly* the privileges that
> their tool needs, not
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > > pgbackrest:
> > > >
> > > > To run pgbackrest as a non-superuser and not the 'postgres' system
> > > > user, grant the pg_backup role
On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > > pgbackrest:
> > >
> > > To run pgbackrest as a non-superuser and not the 'postgres' system
> > > user, grant the pg_backup role to the backrest user and ensure the
> > > backrest
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jan 4, 2016 at 12:55:16PM -0500, Stephen Frost wrote:
> > I'd like to be able to include, in both of those, a simple set of
> > instructions for granting the necessary rights to the user who is
> > running those processes. A set of rights which
On Mon, Jan 4, 2016 at 12:55:16PM -0500, Stephen Frost wrote:
> I'd like to be able to include, in both of those, a simple set of
> instructions for granting the necessary rights to the user who is
> running those processes. A set of rights which an administrator can go
> look up and easily read
On Wed, Jan 6, 2016 at 11:13 AM, Stephen Frost wrote:
> I just wanted to start off by saying thank you for taking the time read
> and comment with your thoughts on this concept. I was a bit frustrated
> about it feeling rather late, but appreciate the comments which have
> been made as they've ce
Robert, Noah,
I just wanted to start off by saying thank you for taking the time read
and comment with your thoughts on this concept. I was a bit frustrated
about it feeling rather late, but appreciate the comments which have
been made as they've certainly been constructive.
* Robert Haas (rober
On Mon, Jan 04, 2016 at 12:55:16PM -0500, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> I'm approaching this largely from a 3rd-party application perspective.
> There are two examples off-hand which I'm consideri
On Mon, Jan 4, 2016 at 5:22 PM, Stephen Frost wrote:
>> So, is this another case where the support is all in off-list fora and
>> thus invisible, or can you point to specific on-list discussions where
>> it was supported, and to the opinions offered in support? I don't
>> really remember many opi
On Mon, Jan 4, 2016 at 4:56 PM, Stephen Frost wrote:
>> First, it's not really going to matter to users very much whether the
>> command to enable one of these features is a single GRANT command or a
>> short sequence of GRANT commands executed one after another. So even
>> if we don't have roles
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 3:07 PM, Stephen Frost wrote:
> > I'm not sure it's entirely relevant now- I've outlined the reasoning in
> > my email to Noah as a, hopefully, pretty comprehensive summary. If that
> > doesn't sway your minds then it seems unl
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 12:55 PM, Stephen Frost wrote:
> > I'd like to be able to include, in both of those, a simple set of
> > instructions for granting the necessary rights to the user who is
> > running those processes. A set of rights which an ad
On Mon, Jan 4, 2016 at 3:07 PM, Stephen Frost wrote:
> I'm not sure it's entirely relevant now- I've outlined the reasoning in
> my email to Noah as a, hopefully, pretty comprehensive summary. If that
> doesn't sway your minds then it seems unlikely that a reference to a
> thread from 6 months or
On Mon, Jan 4, 2016 at 12:55 PM, Stephen Frost wrote:
> I'd like to be able to include, in both of those, a simple set of
> instructions for granting the necessary rights to the user who is
> running those processes. A set of rights which an administrator can go
> look up and easily read and unde
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch wrote:
> > The proposed pg_replication role introduces abstraction that could, as you
> > hope, spare a DBA from studying sets of functions to grant together. The
> > pg_rotate_logfile role, however
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> > Updated patch attached. I'll give it another good look and then commit
> >> > it, barring objections.
> >>
> >> This thread and its satellite[1]
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
>
> > The one argument which you've put forth for adding the complexity of
> > dumping catalog ACLs is that we might reduce the number of defa
Based on the feedback here, I have returned this patch to Needs Review
status. (Waiting on Author would be fairer actually, since we are
waiting for an updated version.)
As far as I can make it from Noah and Robert's comments, what we would
like to see here is a way for pg_dump to output nondefau
On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch wrote:
> On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
>> * Noah Misch (n...@leadboat.com) wrote:
>> I disagree that we would. Having a single
>> set of default roles which provide a sensible breakdown of permissions
>> is a better appr
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 11:55 PM, Stephen Frost wrote:
> > I could go either way on that, really. I don't find namespace to be
> > confusing when used in that way, but I'll change it since others do.
>
> It seems to me that the way patch doe
On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> The one argument which you've put forth for adding the complexity of
> dumping catalog ACLs is that we might reduce the number of default
> roles provided to the user.
Right. If "GRANT EXEC
On Thu, Dec 31, 2015 at 1:50 AM, Robert Haas wrote:
> Under those circumstances, it seems very dubious to proceed
> with this. Michael seems to think that we can go ahead and start
> changing things and sort out whatever is broken later, but that
> doesn't sound like a very good plan to me.
I me
On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
>> > Updated patch attached. I'll give it another good look and then commit
>> > it, barring objections.
>>
>> This thread and its satellite[1] have worked their way through a few designs.
>> At first,
On Tue, Dec 29, 2015 at 11:55 PM, Stephen Frost wrote:
> I could go either way on that, really. I don't find namespace to be
> confusing when used in that way, but I'll change it since others do.
It seems to me that the way patch does it is fine..
--
Michael
--
Sent via pgsql-hackers mailing
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2015/12/23 7:23, Stephen Frost wrote:
> > Updated patch attached. I'll give it another good look and then commit
> > it, barring objections.
>
> Just a minor nitpick about a code comment -
>
> /*
> + * Check that the user
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> > Updated patch attached. I'll give it another good look and then commit
> > it, barring objections.
>
> This thread and its satellite[1] have worked their way through a few designs.
> At first, it was adding role attributes, alongside existing att
Hi,
On 2015/12/23 7:23, Stephen Frost wrote:
> Updated patch attached. I'll give it another good look and then commit
> it, barring objections.
Just a minor nitpick about a code comment -
/*
+ * Check that the user is not trying to create a role in the reserved
+ * "pg_" namespace
On Tue, Dec 22, 2015 at 05:23:47PM -0500, Stephen Frost wrote:
> > >> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost
> > >> wrote:
> > >>> Updated and rebased patch attached which takes the 'pg_switch_xlog'
> > >>> default role back out, leaving us with:
> > >>>
> > >>> pg_monitor - View privileg
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 22, 2015 at 2:54 PM, Amit Langote
> wrote:
> > On 2015/12/22 14:05, Michael Paquier wrote:
> >> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote:
> >>> Updated and rebased patch attached which takes the 'pg_switch_xlog'
> >>>
On Tue, Dec 22, 2015 at 2:54 PM, Amit Langote
wrote:
> On 2015/12/22 14:05, Michael Paquier wrote:
>> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote:
>>> Updated and rebased patch attached which takes the 'pg_switch_xlog'
>>> default role back out, leaving us with:
>>>
>>> pg_monitor - View
On 2015/12/22 14:05, Michael Paquier wrote:
> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote:
>> Updated and rebased patch attached which takes the 'pg_switch_xlog'
>> default role back out, leaving us with:
>>
>> pg_monitor - View privileged info
>> pg_backup - start/stop backups, switch xl
On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote:
> Updated and rebased patch attached which takes the 'pg_switch_xlog'
> default role back out, leaving us with:
>
> pg_monitor - View privileged info
> pg_backup - start/stop backups, switch xlog, create restore points
> pg_replay - Pause/resum
Michael, all,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> OK, let's do so then by having this one fall under pg_backup. Let's
> not be my grunting concerns be an obstacle for this patch, and we
> could still change it afterwards in this release beta cycle anyway
> based on user feedback
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Dec 1, 2015 at 9:18 AM, Michael Paquier
> wrote:
> > OK, let's do so then by having this one fall under pg_backup. Let's
> > not be my grunting concerns be an obstacle for this patch, and we
> > could still change it afterwar
On Tue, Dec 1, 2015 at 9:18 AM, Michael Paquier
wrote:
> On Tue, Dec 1, 2015 at 3:32 AM, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote:
>>> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> >> On Thu, Nov 1
On Tue, Dec 1, 2015 at 3:32 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote:
>> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
>> >> > * Michael Paq
Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > > I can think of a use-case for a user who can call pg_switch_xlog, but
> > > not pg_start_backup()/pg_stop_backup(), but I have to admit that it
> > > seems rather limited and I'm on the fence about it being a worthwhile
> >
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
> >> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> >> It seems wei
On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
>> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> >> It seems weird to not have a dedicated role for pg_switch_xlog.
>>
On Tuesday, November 24, 2015, Alvaro Herrera
wrote:
> Stephen Frost wrote:
>
> > Even so, in the interest of having more fine-grained permission
> > controls, I've gone ahead and added a pg_switch_xlog default role.
> > Note that this means that pg_switch_xlog() can be called by both
> > pg_swit
Stephen Frost wrote:
> Even so, in the interest of having more fine-grained permission
> controls, I've gone ahead and added a pg_switch_xlog default role.
> Note that this means that pg_switch_xlog() can be called by both
> pg_switch_xlog roles and pg_backup roles. I'd be very much against
> rem
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Nov 21, 2015 at 2:29 AM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > Even so, in the interest of having more fine-grained permission
> > controls, I've gone ahead and added a pg_switch_xl
On Sat, Nov 21, 2015 at 2:29 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> Even so, in the interest of having more fine-grained permission
> controls, I've gone ahead and added a pg_switch_xlog default role.
> Note that this means that pg_switch_xlog() can be ca
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> It seems weird to not have a dedicated role for pg_switch_xlog.
> >
> > I didn't add a pg_switch_xlog default role in this patch
On 11/19/15 2:13 AM, Michael Paquier wrote:
> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> It seems weird to not have a dedicated role for pg_switch_xlog.
>>
>> I didn't add a pg_switch_xlog default role in this patch series, but
On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> It seems weird to not have a dedicated role for pg_switch_xlog.
>
> I didn't add a pg_switch_xlog default role in this patch series, but
> would be happy to do so if that's the consensus.
Michael,
Thanks for the review!
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> Patch needs a rebase, some catalog OIDs and there was a conflict in misc.c
> (see attached for the rebase. none of the comments mentioning issues are
> fixed by it).
Done (did it a bit differently from what yo
On Wed, Nov 18, 2015 at 10:06 PM, Michael Paquier wrote:
>
>
> On Wed, Sep 30, 2015 at 8:11 PM, Stephen Frost wrote:
> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> >> I agree with Robert's earlier point that this needs to be split into
> >> multiple patches, which can then be reviewed and d
On Wed, Sep 30, 2015 at 8:11 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> I agree with Robert's earlier point that this needs to be split into
>> multiple patches, which can then be reviewed and discussed
>> separately. Pending that, I'm going to mark this as "Waitin
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> I agree with Robert's earlier point that this needs to be split into
> multiple patches, which can then be reviewed and discussed
> separately. Pending that, I'm going to mark this as "Waiting on
> author" in the commitfest.
Attached is an initial sp
On Sat, Jul 11, 2015 at 6:06 AM, Heikki Linnakangas wrote:
> On 05/08/2015 07:35 AM, Stephen Frost wrote:
>> In consideration of the fact that you can't create schemas which start
>> with "pg_" and therefore the default search_path wouldn't work for that
>> user, and that we also reserve "pg_" for
On 05/08/2015 07:35 AM, Stephen Frost wrote:
Gavin,
* Gavin Flower (gavinflo...@archidevsys.co.nz) wrote:
What if I had a company with several subsidiaries using the same
database, and want to prefix roles and other things with the
subsidiary's initials? (I am not saying this would be a good
ar
Gavin,
* Gavin Flower (gavinflo...@archidevsys.co.nz) wrote:
> What if I had a company with several subsidiaries using the same
> database, and want to prefix roles and other things with the
> subsidiary's initials? (I am not saying this would be a good
> architecture!!!)
If you admit that it's n
On Wed, Apr 29, 2015 at 8:20 PM, Alvaro Herrera
wrote:
>> Finally, you've got the idea of making pg_ a reserved prefix for
>> roles, adding some predefined roles, and giving them some predefined
>> privileges. That should be yet another patch.
>
> On this part I have a bit of a problem -- the pre
On 30/04/15 12:20, Alvaro Herrera wrote:
Robert Haas wrote:
I think that if you commit this the way you have it today, everybody
will go, oh, look, Stephen committed something, but it looks
complicated, I won't pay attention.
Yeah, that sucks.
Finally, you've got the idea of making pg_ a res
Robert Haas wrote:
> I think that if you commit this the way you have it today, everybody
> will go, oh, look, Stephen committed something, but it looks
> complicated, I won't pay attention.
Yeah, that sucks.
> Finally, you've got the idea of making pg_ a reserved prefix for
> roles, adding some
On Wed, Apr 29, 2015 at 10:47 AM, Stephen Frost wrote:
> Here is the latest revision of this patch.
I think this patch is too big and does too many things. It should be
broken up into small patches which can be discussed and validated
independently. The fact that your commit message is incredib
Robert, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > The tricky part of this seems to me to be the pg_dump changes. The
> > > new catalog flag seems a little sketchy to me; wouldn't it be bett
Robert,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost wrote:
> > > Clearly, further testing and documentation is required and I'll be
> > > getting to that over the next couple of days, but it's pretty
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost wrote:
> > Clearly, further testing and documentation is required and I'll be
> > getting to that over the next couple of days, but it's pretty darn late
> > and I'm currently getting libpq undef
On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>> > REVOKE'ing access *without* removing the permissions checks would defeat
>> > the intent of these changes, which is to allow an administrator to grant
>> > the ability for
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > REVOKE'ing access *without* removing the permissions checks would defeat
> > the intent of these changes, which is to allow an administrator to grant
> > the ability for a certain set of users to cancel and/or terminate
> > backend
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> That seems fairly ugly. Why would we need a new, duplicative function
>> here? (Apologies if the reasoning was spelled out upthread, I've not
>> been paying much attention.)
> Currently, those functions allow users to signal back
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > ... Lastly, there is the question of pg_cancel_backend and
> > pg_terminate_backend. My thinking on this is to create a new
> > 'pg_signal_backend' which admins could grant access to and leave the
> > existing functions alone (mod
Stephen Frost writes:
> ... Lastly, there is the question of pg_cancel_backend and
> pg_terminate_backend. My thinking on this is to create a new
> 'pg_signal_backend' which admins could grant access to and leave the
> existing functions alone (modulo the change for has_privs_of_role as
> discuss
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> Alright, I've got an initial patch to do this for pg_start/stop_backup,
> pg_switch_xlog, and pg_create_restore_point. The actual backend changes
> are quite small, as expected. I'll add in the changes for the other
> functions being discussed a
Peter, all,
* Peter Eisentraut (pete...@gmx.net) wrote:
> Why are we not using roles and function execute privileges for this?
Alright, I've got an initial patch to do this for pg_start/stop_backup,
pg_switch_xlog, and pg_create_restore_point. The actual backend changes
are quite small, as expec
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 2/28/15 10:10 PM, Stephen Frost wrote:
> > * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> >> I have attached and updated patch for review.
> >
> > Thanks! I've gone over this and made quite a few documentation and
> > comment
On 2/28/15 10:10 PM, Stephen Frost wrote:
> Adam,
>
> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
>> I have attached and updated patch for review.
>
> Thanks! I've gone over this and made quite a few documentation and
> comment updates, but not too much else, so I'm prett
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Let's go with the "NO_" prefix then ... that seems better to me than no
> separator.
Works for me.
Thanks!
Stephen
signature.asc
Description: Digital signature
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > That being so, I would consider the idea that the NO bit is a separate
> > word rather than run together with the actual privilege name. And given
> > that CREATE has all the options default to "NO", there
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > That being so, I would consider the idea that the NO bit is a separate
> > word rather than run together with the actual privilege name. And given
> > that CREATE has all the options default to "NO", there is no need to
> > have
Alvaro Herrera writes:
> That being so, I would consider the idea that the NO bit is a separate
> word rather than run together with the actual privilege name. And given
> that CREATE has all the options default to "NO", there is no need to
> have these options at all in CREATE, is there?
FWIW,
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > So you'd advocate EXCLUSIVE_BACKUP and NOEXCLUSIVE_BACKUP? Or
> > NO_EXCLUSIVE_BACKUP? Or..? If this was a green field, I think we might
> > actually use spaces instead, but I'm really not sure we want to go
>
Stephen Frost wrote:
> So you'd advocate EXCLUSIVE_BACKUP and NOEXCLUSIVE_BACKUP? Or
> NO_EXCLUSIVE_BACKUP? Or..? If this was a green field, I think we might
> actually use spaces instead, but I'm really not sure we want to go
> through and redo everything that way at this point.. We'd end up
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> If we were choosing those names nowadays, would we choose CREATEDB at
> >> all in the first place? I think we'd go for something more verbose,
> >> probably CREATE_DATABASE.
Stephen Frost writes:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> If we were choosing those names nowadays, would we choose CREATEDB at
>> all in the first place? I think we'd go for something more verbose,
>> probably CREATE_DATABASE. (CREATEROLE is not as old as CREATEDB, but my
>>
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Adam Brightwell wrote:
> > I'm not sure there was an actual discussion on the topic. Though, at one
> > point I had proposed it as one of the forms of this attribute. Personally,
> > I think it is easier to read with the underscore. But, ultim
1 - 100 of 186 matches
Mail list logo
