On Mon, Jan 30, 2017 at 5:33 AM, Simon Riggs wrote:
> I would call these "super privileges".
>
> Peter suggests that we have a much more flexible structure for
> super-privileges.
>
> In Peter's model, Tom's suggestion woud be to grant all of these
> automatically to
On 30 January 2017 at 16:34, Peter Eisentraut
wrote:
> On 1/30/17 9:04 AM, Simon Riggs wrote:
>> all I want in this release is
>> super-ownership.
>
> What exactly is super-ownership, and what problems does it solve?
The problem is that there is no easy way for
On 30 January 2017 at 16:43, Tom Lane wrote:
> Simon Riggs writes:
>> Agreed. Let me reiterate: all I want in this release is
>> super-ownership.
>
> While I'm not entirely convinced whether super-ownership is a good idea
> or not, I am pretty sure that
Simon Riggs writes:
> Agreed. Let me reiterate: all I want in this release is
> super-ownership.
While I'm not entirely convinced whether super-ownership is a good idea
or not, I am pretty sure that rushing to get it into v10 is a bad idea.
This is a rather fundamental
On 1/30/17 9:04 AM, Simon Riggs wrote:
> all I want in this release is
> super-ownership.
What exactly is super-ownership, and what problems does it solve?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 30 January 2017 at 14:43, Stephen Frost wrote:
>
> > We need to make sure that we're actually talking about the same things
> > here, because we've now shifted from ownership-like privileges to those
> > privielges
On 1/29/17 7:44 PM, Stephen Frost wrote:
> I would think we'd either do this with a default role or a role
> attribute.
That's not how I think about it. I think this would be a separate
aclitem[] stored somewhere. The pg_xxx_aclcheck() functions could
consult that implicitly.
--
Peter
On Fri, Jan 27, 2017 at 05:48:46PM -0500, Peter Eisentraut wrote:
> On 1/26/17 1:25 PM, Simon Riggs wrote:
> > That should include the ability to dump all objects, yet without
> > any security details. And it should allow someone to setup logical
> > replication easily, including both trigger
On 30 January 2017 at 14:43, Stephen Frost wrote:
> We need to make sure that we're actually talking about the same things
> here, because we've now shifted from ownership-like privileges to those
> privielges which can be GRANT'd, and the two are far from the same.
Agreed.
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 27 January 2017 at 22:48, Peter Eisentraut
> wrote:
> > On 1/26/17 1:25 PM, Simon Riggs wrote:
> >> That should include the ability to dump all objects, yet without any
> >> security details. And it should
On 27 January 2017 at 22:48, Peter Eisentraut
wrote:
> On 1/26/17 1:25 PM, Simon Riggs wrote:
>> That should include the ability to dump all objects, yet without any
>> security details. And it should allow someone to setup logical
>> replication easily,
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 1/29/17 4:44 PM, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >>On 1/26/17 1:25 PM, Simon Riggs wrote:
> >>>That should include the ability to dump all objects, yet without any
> >>>security details.
On 1/29/17 4:44 PM, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
On 1/26/17 1:25 PM, Simon Riggs wrote:
That should include the ability to dump all objects, yet without any
security details. And it should allow someone to setup logical
replication easily,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/26/17 1:25 PM, Simon Riggs wrote:
> > That should include the ability to dump all objects, yet without any
> > security details. And it should allow someone to setup logical
> > replication easily, including both trigger based and
On 1/26/17 1:25 PM, Simon Riggs wrote:
> That should include the ability to dump all objects, yet without any
> security details. And it should allow someone to setup logical
> replication easily, including both trigger based and new logical
> replication. And GRANT ON ALL should work.
This
On 26 January 2017 at 17:37, Peter Eisentraut
wrote:
> On 1/24/17 8:19 AM, Tom Lane wrote:
>> What about just saying that the database owner has those privileges?
>> After all, the ultimate privilege of an owner is to drop the object
>> (and then remake it as she
On Thursday, January 26, 2017, Michael Banck
wrote:
> On Thu, Jan 26, 2017 at 12:37:44PM -0500, Peter Eisentraut wrote:
> > On 1/24/17 8:19 AM, Tom Lane wrote:
> > > What about just saying that the database owner has those privileges?
> > > After all, the ultimate
On Thu, Jan 26, 2017 at 12:37:44PM -0500, Peter Eisentraut wrote:
> On 1/24/17 8:19 AM, Tom Lane wrote:
> > What about just saying that the database owner has those privileges?
> > After all, the ultimate privilege of an owner is to drop the object
> > (and then remake it as she pleases), and the
On 1/24/17 8:19 AM, Tom Lane wrote:
> What about just saying that the database owner has those privileges?
> After all, the ultimate privilege of an owner is to drop the object
> (and then remake it as she pleases), and the DB owner has that option
> w.r.t. the whole database. So I'm not sure we
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> So I was thinking about various annoying admin/security issues
> recently, so I came up with this: a new type of user called a
> “superowner”. It’s somewhere between a superuser and a normal user.
I like the general idea, but I'm not really
On 24 January 2017 at 13:19, Tom Lane wrote:
> Simon Riggs writes:
>> So I was thinking about various annoying admin/security issues
>> recently, so I came up with this: a new type of user called a
>> “superowner”. It’s somewhere between a superuser
Simon Riggs writes:
> So I was thinking about various annoying admin/security issues
> recently, so I came up with this: a new type of user called a
> “superowner”. It’s somewhere between a superuser and a normal user.
> Superowner would own all objects defined by users,
22 matches
Mail list logo