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 problems.
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 providing some scenarios
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.
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. We don't
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 want
On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs si...@2ndquadrant.com 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)
Robert Haas robertmh...@gmail.com 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.
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.
Josh Berkus j...@agliodbs.com 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
On Fri, Mar 27, 2009 at 12:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 often
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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,
Gregory Stark wrote:
Guillaume Smet guillaume.s...@gmail.com writes:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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;.
Josh Berkus j...@agliodbs.com 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
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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
Guillaume Smet guillaume.s...@gmail.com writes:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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
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
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.
Heh. That'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
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 solve
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
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 want
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs si...@2ndquadrant.com 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.
--On Mittwoch, März 11, 2009 21:45:00 + Simon Riggs
si...@2ndquadrant.com 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
Greg Stark st...@enterprisedb.com writes:
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Mar 11, 2009 at 9:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs si...@2ndquadrant.com 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
27 matches
Mail list logo
