Josh Berkus wrote:
> Bruce, Simon,
>
> > I don't think there is an agreed todo item there. We were in the middle
> > of discussing other ideas and this is the wrong time to have a longer
> > debate on the topic. We should not squash other ideas by putting this as
> > a todo item yet.
>
> I agree.
Bruce, Simon,
I don't think there is an agreed todo item there. We were in the middle
of discussing other ideas and this is the wrong time to have a longer
debate on the topic. We should not squash other ideas by putting this as
a todo item yet.
I agree. We don't have consensus on the TODO.
Simon Riggs wrote:
>
> On Fri, 2009-03-27 at 23:25 -0400, Bruce Momjian wrote:
> > Josh Berkus wrote:
> > >
> > > > Josh, this isn't a rejection. Both Tom and I asked for more exploration
> > > > of the implications of doing as you suggest. Tom has been more helpful
> > > > than I was in providin
On Fri, 2009-03-27 at 23:25 -0400, Bruce Momjian wrote:
> Josh Berkus wrote:
> >
> > > Josh, this isn't a rejection. Both Tom and I asked for more exploration
> > > of the implications of doing as you suggest. Tom has been more helpful
> > > than I was in providing some scenarios that would cause
Josh Berkus wrote:
>
> > Josh, this isn't a rejection. Both Tom and I asked for more exploration
> > of the implications of doing as you suggest. Tom has been more helpful
> > than I was in providing some scenarios that would cause problems. It is
> > up to you to solve the problems, which is ofte
On Fri, Mar 27, 2009 at 12:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think this is way over-engineered. All we really need here is a
>> command along the lines of RESET ALL AS CURRENT USER that gives every
>> GUC the value it would have had if you logged in under the current
>> user's ac
Josh Berkus writes:
>> Simon's idea of "profiles" sounds worth pursuing to me, but clearly
>> it's not happening for 8.4.
> I don't see why having a *separate* concept of profiles in addition to
> the ROLES is helpful. It seems like building a whole new house when all
> we really need is to ex
Tom,
BTW, does pg_dumpall know to dump ALTER USER SET settings attached
to built-in roles (such as the proposed "autovacuum" role)? I'd bet
it doesn't do that. Even if it does, that seems like a more awkward
way to push settings over to a new installation than copying your
postgresql.conf file
Robert Haas writes:
> I think this is way over-engineered. All we really need here is a
> command along the lines of RESET ALL AS CURRENT USER that gives every
> GUC the value it would have had if you logged in under the current
> user's account. Simple, clean, no new keywords.
Doesn't do anyth
On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs wrote:
> On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
>
>> I was just noticing that doing SET ROLE changes the current session's
>> priviledges, but not any runtime configuration parameters (like work_mem
>> or statement_timeout) associated wit
On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
> I was just noticing that doing SET ROLE changes the current session's
> priviledges, but not any runtime configuration parameters (like work_mem
> or statement_timeout) associated with the new role.
>
> This is as documented (although I w
Josh Berkus writes:
> Tom Lane wrote:
>> The question is why this should be tied to SET ROLE, which already has
>> well defined semantics that don't include any such behavior.
> Mostly because we don't have anywhere else to hang a "settings profile"
> than ROLEs.
So we should fix that, if we wa
Tom Lane wrote:
Josh Berkus writes:
What I want to be able to do is to set different bunches of resource
management settings for various non-login inherited roles, and be able
to choose profiles via a SET ROLE. The reason to do this, btw, instead
of defining various login roles, is that diff
Josh Berkus writes:
> What I want to be able to do is to set different bunches of resource
> management settings for various non-login inherited roles, and be able
> to choose profiles via a SET ROLE. The reason to do this, btw, instead
> of defining various login roles, is that different logi
Gregory Stark wrote:
Guillaume Smet writes:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
SET ROLE special WITH SETTINGS
... or similar; I'd need to find an existing keyword which works.
Perhaps something like "SET ROLE special NEW SESSION;".
It solves a problem mentioned by Tom as
Guillaume Smet writes:
> On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
>> SET ROLE special WITH SETTINGS
>>
>> ... or similar; I'd need to find an existing keyword which works.
>
> Perhaps something like "SET ROLE special NEW SESSION;".
>
> It solves a problem mentioned by Tom as it's very
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
> SET ROLE special WITH SETTINGS
>
> ... or similar; I'd need to find an existing keyword which works.
Perhaps something like "SET ROLE special NEW SESSION;".
It solves a problem mentioned by Tom as it's very clear that it's a
new session so wh
On Thursday 12 March 2009 21:39:54 Josh Berkus wrote:
> > Josh, this isn't a rejection. Both Tom and I asked for more exploration
> > of the implications of doing as you suggest. Tom has been more helpful
> > than I was in providing some scenarios that would cause problems. It is
> > up to you to s
Josh, this isn't a rejection. Both Tom and I asked for more exploration
of the implications of doing as you suggest. Tom has been more helpful
than I was in providing some scenarios that would cause problems. It is
up to you to solve the problems, which is often possible.
OK, well, barring th
On Thu, 2009-03-12 at 08:26 -0700, Josh Berkus wrote:
> Tom,
>
> > Discuss the implications of changing such a GUC partway
> > through this sequence. For extra credit, explain what would happen if
> > it were set via ALTER ROLE SET for one role or the other.
> >
> > In short: -1 from me.
>
> He
Tom,
> Discuss the implications of changing such a GUC partway
> through this sequence. For extra credit, explain what would happen if
> it were set via ALTER ROLE SET for one role or the other.
>
> In short: -1 from me.
Heh. That's your best rejection yet. Someday I'll print out all the
reje
On Wed, Mar 11, 2009 at 9:21 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs wrote:
>>>
>>> On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
This is as documented (although I want to add a line to SET ROLE docs)
but is it the behavior we wa
Greg Stark writes:
> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs wrote:
>>
>> On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
>>> This is as documented (although I want to add a line to SET ROLE docs)
>>> but is it the behavior we want? I for one would like SET ROLE to change
>>> runtime
--On Mittwoch, März 11, 2009 21:45:00 + Simon Riggs
wrote:
This is as documented (although I want to add a line to SET ROLE docs)
but is it the behavior we want? I for one would like SET ROLE to change
runtime configs.
Sounds good to me, but you may want to explore what problems that mi
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs wrote:
>
> On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
>> This is as documented (although I want to add a line to SET ROLE docs)
>> but is it the behavior we want? I for one would like SET ROLE to change
>> runtime configs.
>
> Sounds good to
On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
> I was just noticing that doing SET ROLE changes the current session's
> priviledges, but not any runtime configuration parameters (like work_mem
> or statement_timeout) associated with the new role.
>
> This is as documented (although I w
All,
I was just noticing that doing SET ROLE changes the current session's
priviledges, but not any runtime configuration parameters (like work_mem
or statement_timeout) associated with the new role.
This is as documented (although I want to add a line to SET ROLE docs)
but is it the behavio
27 matches
Mail list logo
