On Fri, May 6, 2016 at 12:12 PM, Stephen Frost wrote:
> I've been thinking the same, my flight just arrived into DC and I'll be
> pushing it all shortly after I get home.
To be clear, I wasn't simply saying that you should commit these
patches today instead of tomorrow, although I'm glad you did
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, May 5, 2016 at 10:41 AM, Stephen Frost wrote:
> > Barring objections or concerns, I'll push this sometime tomorrow
> > (probably after I get back to DC).
>
> It really would have been good to get this stuff done sooner. By the
> time you pus
Robert,
On Friday, May 6, 2016, Robert Haas wrote:
> On Thu, May 5, 2016 at 10:41 AM, Stephen Frost > wrote:
> > Barring objections or concerns, I'll push this sometime tomorrow
> > (probably after I get back to DC).
>
> It really would have been good to get this stuff done sooner. By the
> ti
On Thu, May 5, 2016 at 10:41 AM, Stephen Frost wrote:
> Barring objections or concerns, I'll push this sometime tomorrow
> (probably after I get back to DC).
It really would have been good to get this stuff done sooner. By the
time you push this, there will barely be enough time for a buildfarm
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote:
> > > On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> > >> Based on our discussion at PGConf.US and the comments up-thread from
> > >> Tom, I'
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote:
> > On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> >> Based on our discussion at PGConf.US and the comments up-thread from
> >> Tom, I'll work up a patch to remove those checks around SET R
On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote:
> On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
>> Based on our discussion at PGConf.US and the comments up-thread from
>> Tom, I'll work up a patch to remove those checks around SET ROLE and
>> friends which were trying to prevent defau
Robert Haas wrote:
> On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> > Working up a patch to remove these checks should be pretty quickly done
> > (iirc, I've actually got an independent patch around from when I added
> > them, just need to find it and then go through the committed patche
On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> Based on our discussion at PGConf.US and the comments up-thread from
> Tom, I'll work up a patch to remove those checks around SET ROLE and
> friends which were trying to prevent default roles from possibly being
> made to own objects.
>
> Sh
Robert, all,
[... comments elsewhere made me realize I hadn't actually sent this when
I thought I had, my apologies on that ...]
* Robert Haas (robertmh...@gmail.com) wrote:
> Great. But there's no particular use case served by a lot of things
> which are natural outgrowths of the rest of the sy
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 15, 2016 at 11:56 AM, Stephen Frost wrote:
> > Perhaps it would be helpful to return to the initial goal of these
> > default roles.
> >
> > We've identified certain privileges which are currently superuser-only
> > and we would l
On Fri, Apr 15, 2016 at 11:56 AM, Stephen Frost wrote:
> Perhaps it would be helpful to return to the initial goal of these
> default roles.
>
> We've identified certain privileges which are currently superuser-only
> and we would like to be able to be GRANT those to non-superuser roles.
> Where o
On Fri, Apr 15, 2016 at 8:56 AM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost
> wrote:
> > > Requiring that SET ROLE be allowed will mean that many more paths must
> > > be checked and adjusted, such as in all
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost wrote:
> > Requiring that SET ROLE be allowed will mean that many more paths must
> > be checked and adjusted, such as in all of the CreateObject statements
> > and potentionally many other paths
On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost wrote:
> Requiring that SET ROLE be allowed will mean that many more paths must
> be checked and adjusted, such as in all of the CreateObject statements
> and potentionally many other paths that I'm not thinking of here, not
> the least of which are a
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2016/04/14 2:10, Stephen Frost wrote:
> >> Amit Langote > writes:
> >>> I observe this:
> >>
> >>> postgres=# SET ROLE TO NONE;
> >>> SET
> >>> postgres=# SET ROLE TO nonexistent;
> >>> ERROR: role "nonexistent" does not exist
> >>>
Hi Stephen,
On 2016/04/14 2:10, Stephen Frost wrote:
>> Amit Langote > writes:
>>> I observe this:
>>
>>> postgres=# SET ROLE TO NONE;
>>> SET
>>> postgres=# SET ROLE TO nonexistent;
>>> ERROR: role "nonexistent" does not exist
>>> postgres=# SET ROLE TO pg_signal_backend;
>>> ERROR: invalid va
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> From what I've read here I'm thinking Stephen has the right idea.
Thanks. Additionally, your comments make me realize an existing issue,
which is superuser-only but I'll address shortly anyway (we have far too
many users running around as
On Wed, Apr 13, 2016 at 3:53 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > On Wednesday, April 13, 2016, Tom Lane wrote:
> > >> If you want to prevent that, I think it needs to be done somewhere
> else
> > >> than here. What about "ALTER OWNE
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Wednesday, April 13, 2016, Tom Lane wrote:
> >> If you want to prevent that, I think it needs to be done somewhere else
> >> than here. What about "ALTER OWNER TO pg_signal_backend", for instance?
>
> > Checks are included in
On Wed, Apr 13, 2016 at 2:10 PM, Tom Lane wrote:
> Stephen Frost writes:
>> On Wednesday, April 13, 2016, Tom Lane wrote:
>>> If you want to prevent that, I think it needs to be done somewhere else
>>> than here. What about "ALTER OWNER TO pg_signal_backend", for instance?
>
>> Checks are inclu
Stephen Frost writes:
> On Wednesday, April 13, 2016, Tom Lane wrote:
>> If you want to prevent that, I think it needs to be done somewhere else
>> than here. What about "ALTER OWNER TO pg_signal_backend", for instance?
> Checks are included in that code path to disallow it.
If there are such
Tom,
On Wednesday, April 13, 2016, Tom Lane wrote:
> Stephen Frost > writes:
> > On Wednesday, April 13, 2016, Robert Haas > wrote:
> >> Well ... yeah. But that doesn't mean it should be impossible to SET
> >> to that role itself. I'm a little worried that could create strange
> >> corner cas
Stephen Frost writes:
> On Wednesday, April 13, 2016, Robert Haas wrote:
>> Well ... yeah. But that doesn't mean it should be impossible to SET
>> to that role itself. I'm a little worried that could create strange
>> corner cases.
> Being able to create objects owned by a default role was one
On Wed, Apr 13, 2016 at 1:24 PM, Stephen Frost wrote:
> On Wednesday, April 13, 2016, Robert Haas wrote:
>>
>> On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost wrote:
>> >> What I'd like to know is why it rejects that at all. What's the point
>> >> of having roles you can't SET to?
>> >
>> > To u
On Wednesday, April 13, 2016, Robert Haas wrote:
> On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost > wrote:
> >> What I'd like to know is why it rejects that at all. What's the point
> >> of having roles you can't SET to?
> >
> > To use them to GRANT access to other roles, which was the goal of
On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost wrote:
>> What I'd like to know is why it rejects that at all. What's the point
>> of having roles you can't SET to?
>
> To use them to GRANT access to other roles, which was the goal of the
> default roles system to begin with.
Well ... yeah. But
Tom, all,
On Wednesday, April 13, 2016, Tom Lane wrote:
> Amit Langote > writes:
> > I observe this:
>
> > postgres=# SET ROLE TO NONE;
> > SET
> > postgres=# SET ROLE TO nonexistent;
> > ERROR: role "nonexistent" does not exist
> > postgres=# SET ROLE TO pg_signal_backend;
> > ERROR: invalid
Amit Langote writes:
> I observe this:
> postgres=# SET ROLE TO NONE;
> SET
> postgres=# SET ROLE TO nonexistent;
> ERROR: role "nonexistent" does not exist
> postgres=# SET ROLE TO pg_signal_backend;
> ERROR: invalid value for parameter "role": "pg_signal_backend"
> Is that behavior deliberat
On Wed, Apr 13, 2016 at 8:49 AM, Michael Paquier
wrote:
> On Wed, Apr 13, 2016 at 5:58 PM, Amit Langote
> wrote:
>> Is that behavior deliberate? Might it be better to handle the case
>> specially much as setting to "none" works? Such as:
>>
>> ERROR: cannot set to reserved role "pg_signal_backen
On Wed, Apr 13, 2016 at 5:58 PM, Amit Langote
wrote:
> Is that behavior deliberate? Might it be better to handle the case
> specially much as setting to "none" works? Such as:
>
> ERROR: cannot set to reserved role "pg_signal_backend"
>
> Sorry if I have missed any discussion where such a choice
31 matches
Mail list logo