Thread: Should SET ROLE inherit config params?

Should SET ROLE inherit config params?

From
Josh Berkus
Date:
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 behavior we want?  I for one would like SET ROLE to change 
runtime configs.

--Josh


Re: Should SET ROLE inherit config params?

From
Simon Riggs
Date:
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 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 might
cause so we can avoid screwing up. Perhaps it could be an option?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



Re: Should SET ROLE inherit config params?

From
Greg Stark
Date:
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs <simon@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.
>
> Sounds good to me, but you may want to explore what problems that might
> cause so we can avoid screwing up. Perhaps it could be an option?

Well for one thing pg_dump uses SET ROLE extensively and it sets
parameters assuming they'll stay set

--
greg


Re: Should SET ROLE inherit config params?

From
Bernd Helmle
Date:
--On Mittwoch, März 11, 2009 21:45:00 +0000 Simon Riggs
<simon@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 what problems that might
> cause so we can avoid screwing up. Perhaps it could be an option?

I had exactly the same intention yesterday. Maybe something along the line
of su - is what we want, thus expanding such a functionality with an
optional argument to SET ROLE.


--  Thanks
                   Bernd


Re: Should SET ROLE inherit config params?

From
Tom Lane
Date:
Greg Stark <stark@enterprisedb.com> writes:
> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs <simon@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.

> Well for one thing pg_dump uses SET ROLE extensively and it sets
> parameters assuming they'll stay set

I think this is going to make the already-tricky semantics of GUC
variables completely impossible.  Per-user settings normally establish
the session's RESET values of the variables and can be overridden (for
the session or just for a transaction) by explicit SET.  If the latter
remains true it'd fix Greg's concern about pg_dump, but it's just
mind-bending to think about what RESET means if we try to put this in.
Assume we've done ALTER ROLE SET foo = something for our login
role and ALTER ROLE x SET foo = somethingelse:
start psql
-- foo = something, presumably
SET foo = other;
SET ROLE x;
-- foo still = other, presumably
RESET foo;    -- now what is foo?

(if your answer is "somethingelse", justify this in terms of the
documented behavior of RESET: restore to the session-start value.)
RESET ROLE;    -- now what is foo?

(ie, does this action in itself change foo, and if so why?)


Also, with all the whining I've seen in the past few days about not
making application-breaking incompatible changes, it would seem
appropriate to have a GUC to control whether we have this behavior or
the old one.  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.
        regards, tom lane


Re: Should SET ROLE inherit config params?

From
Robert Haas
Date:
On Wed, Mar 11, 2009 at 9:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@enterprisedb.com> writes:
>> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs <simon@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.
>
>> Well for one thing pg_dump uses SET ROLE extensively and it sets
>> parameters assuming they'll stay set
>
> I think this is going to make the already-tricky semantics of GUC
> variables completely impossible.  Per-user settings normally establish
> the session's RESET values of the variables and can be overridden (for
> the session or just for a transaction) by explicit SET.  If the latter
> remains true it'd fix Greg's concern about pg_dump, but it's just
> mind-bending to think about what RESET means if we try to put this in.
> Assume we've done ALTER ROLE SET foo = something for our login
> role and ALTER ROLE x SET foo = somethingelse:
>
>        start psql
>
>        -- foo = something, presumably
>
>        SET foo = other;
>
>        SET ROLE x;
>
>        -- foo still = other, presumably
>
>        RESET foo;      -- now what is foo?
>
> (if your answer is "somethingelse", justify this in terms of the
> documented behavior of RESET: restore to the session-start value.)
>
>        RESET ROLE;     -- now what is foo?
>
> (ie, does this action in itself change foo, and if so why?)
>
>
> Also, with all the whining I've seen in the past few days about not
> making application-breaking incompatible changes, it would seem
> appropriate to have a GUC to control whether we have this behavior or
> the old one.  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.

Maybe it would make more sense to have some option to SET ROLE or some
separate command that resets all configuration parameters to the
values that they would have had, if you had only logged in as that
other user originally.  I thought "RESET ALL" might do this, but it
seems not.

...Robert


Re: Should SET ROLE inherit config params?

From
Josh Berkus
Date:
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 
rejection e-mails from you and wallpaper my office. ;-)

I guess what I'm really hoping to do is to hack ROLEs into a primitive 
resource management tool.  Maybe this is the wrong approach, but we need 
*something* in this vein, and from an application development perspective 
combining permissions, connections and resource allocation via ROLES makes a 
lot of sense.  The SET ROLE issue comes in pretty much for login management.

-- 
Josh Berkus
PostgreSQL
San Francisco


Re: Should SET ROLE inherit config params?

From
Simon Riggs
Date:
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 your best rejection yet.  Someday I'll print out all the 
> rejection e-mails from you and wallpaper my office. ;-)

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. 

I can't vouch for your taste in wallpaper, but this doesn't deserve a
place in your collection...

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



Re: Should SET ROLE inherit config params?

From
Josh Berkus
Date:
> 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 the context issues, what do people think of the idea?

What I was thinking was that this would be a setting on the SET ROLE 
statement, such as:

SET ROLE special WITH SETTINGS

... or similar; I'd need to find an existing keyword which works.

I think this bypasses a lot of the issues which Tom raises, but I'd want 
to think about the various permutations some more.

--Josh


Re: Should SET ROLE inherit config params?

From
Robert Treat
Date:
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 the problems, which is often possible.
>
> OK, well, barring the context issues, what do people think of the idea?
>
> What I was thinking was that this would be a setting on the SET ROLE
> statement, such as:
>
> SET ROLE special WITH SETTINGS
>
> ... or similar; I'd need to find an existing keyword which works.
>
> I think this bypasses a lot of the issues which Tom raises, but I'd want
> to think about the various permutations some more.
>

How bad of an idea would it be to split set session authorization to be 
privilege specific, and set role to focus on configiuration?

-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com


Re: Should SET ROLE inherit config params?

From
Guillaume Smet
Date:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus <josh@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 session so when you reset the settings to what they were at
session start, you take the default settings of special.

-- 
Guillaume


Re: Should SET ROLE inherit config params?

From
Gregory Stark
Date:
Guillaume Smet <guillaume.smet@gmail.com> writes:

> On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus <josh@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 session so when you reset the settings to what they were at
> session start, you take the default settings of special.

So this is just syntactic sugar for 

SET ROLE;
RESET ALL;

Or is it more or less?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!


Re: Should SET ROLE inherit config params?

From
Josh Berkus
Date:
Gregory Stark wrote:
> Guillaume Smet <guillaume.smet@gmail.com> writes:
> 
>> On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus <josh@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 session so when you reset the settings to what they were at
>> session start, you take the default settings of special.
> 
> So this is just syntactic sugar for 
> 
> SET ROLE;
> RESET ALL;
> 
> Or is it more or less?

No, actually, since RESET ALL does not adopt the config settings of your 
current group role, but only the login role you logged in with, e.g.:

postgres=# alter role manson set work_mem = '1MB';
ALTER ROLE
postgres=# \c - charles
You are now connected to database "postgres" as user "charles".
postgres=> show work_mem; work_mem
---------- 2MB
(1 row)

postgres=> set role manson;
SET
postgres=> reset all;
RESET
postgres=> show work_mem; work_mem
---------- 2MB


I'd like to have that 2nd work_mem call to show "manson's" work_mem, or 1MB.

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 login roles can't 
share the same connection pool.

--Josh



Re: Should SET ROLE inherit config params?

From
Tom Lane
Date:
Josh Berkus <josh@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 different login roles can't 
> share the same connection pool.

The question is why this should be tied to SET ROLE, which already has
well defined semantics that don't include any such behavior.
        regards, tom lane


Re: Should SET ROLE inherit config params?

From
Josh Berkus
Date:
Tom Lane wrote:
> Josh Berkus <josh@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 different login roles can't 
>> share the same connection pool.
> 
> 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.  And currently, we can define settings with roles; the fact 
that those settings materially only apply to login roles and not to 
non-login roles could even be seen as inconsistent.

--Josh


Re: Should SET ROLE inherit config params?

From
Tom Lane
Date:
Josh Berkus <josh@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, if we want a feature like this.

> And currently, we can define settings with roles; the fact 
> that those settings materially only apply to login roles and not to 
> non-login roles could even be seen as inconsistent.

[ shrug... ] The behavior of SET ROLE is defined by the standard.  The
behavior at login is not.
        regards, tom lane


Re: Should SET ROLE inherit config params?

From
Simon Riggs
Date:
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 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.

Thinking some more about the requirements for this and various
objections.

I'm guessing that there's a small cluster of parameters you want to
alter using this. It seems easier to think about those parameters and to
look at ways of managing those. Perhaps what we need is not parameters
on roles, but a related concept: profiles. 

Profiles define the limits and priorities given to certain categories of
work. So one profile might be work_mem = 128M and constraint_exclusion =
on, others could differ. If we invent a new concept, we get to define
the semantics from scratch. Maybe RESET doesn't work with profiles,
maybe you can't change user parameters set by a profile, maybe they
allow you to define maximum values. Maybe. Maybe. Nice clear
distinction: roles manage privileges, profiles manage
resources/optimisation.

The main reason for abstraction is that we can avoid hardcoding resource
management data into applications, so that when we upgrade we don't need
to retune or re-arrange everything.

8.5 obviously. But if some time is given to a coherent design that
focuses on what we actually want rather than on a specific solution, we
may find there is a neat way to do this without breaking anything.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



Re: Should SET ROLE inherit config params?

From
Robert Haas
Date:
On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs <simon@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) associated with the new role.
>>
>> 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.
>
> Thinking some more about the requirements for this and various
> objections.
>
> I'm guessing that there's a small cluster of parameters you want to
> alter using this. It seems easier to think about those parameters and to
> look at ways of managing those. Perhaps what we need is not parameters
> on roles, but a related concept: profiles.

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.

...Robert


Re: Should SET ROLE inherit config params?

From
Tom Lane
Date:
Robert Haas <robertmhaas@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.

Doesn't do anything for autovacuum though...

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.

Simon's idea of "profiles" sounds worth pursuing to me, but clearly
it's not happening for 8.4.
        regards, tom lane


Re: Should SET ROLE inherit config params?

From
Josh Berkus
Date:
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.
>
> 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 expand the garage.

--Josh


Re: Should SET ROLE inherit config params?

From
Tom Lane
Date:
Josh Berkus <josh@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 is to expand the garage.

Simon already pointed out one major reason: we can define the semantics
of such things without creating any backwards-compatibility issues,
whereas fooling with the behavior of roles by themselves is likely to
create some issues.

However, this is all 8.5 material in any case, and I'm going to stop
paying attention now because I'm trying to get to 8.4 beta.
        regards, tom lane


Re: Should SET ROLE inherit config params?

From
Robert Haas
Date:
On Fri, Mar 27, 2009 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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.
>
> Doesn't do anything for autovacuum though...

Nope, but I think that can be solved separately.

...Robert


Re: Should SET ROLE inherit config params?

From
Bruce Momjian
Date:
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 possible.
>
> OK, well, barring the context issues, what do people think of the idea?
>
> What I was thinking was that this would be a setting on the SET ROLE
> statement, such as:
>
> SET ROLE special WITH SETTINGS
>
> ... or similar; I'd need to find an existing keyword which works.
>
> I think this bypasses a lot of the issues which Tom raises, but I'd want
> to think about the various permutations some more.

I have added the following TODO:

    Allow role-specific ALTER ROLE SET variable settings to be processed
    independently of login; SET ROLE does not process role-specific variable
    settings

        * http://archives.postgresql.org/message-id/49B82CD7.20802@agliodbs.com

and the attached patch which better documents our current behavior.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/alter_role.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/alter_role.sgml,v
retrieving revision 1.11
diff -c -c -r1.11 alter_role.sgml
*** doc/src/sgml/ref/alter_role.sgml    14 Nov 2008 10:22:45 -0000    1.11
--- doc/src/sgml/ref/alter_role.sgml    28 Mar 2009 03:23:57 -0000
***************
*** 79,97 ****
     password is <literal>MD5</>-encrypted.
    </para>

!   <para>
!    The remaining variants change a role's session default for
!    a specified configuration variable.  Whenever the role subsequently
!    starts a new session, the specified value becomes the session default,
!    overriding whatever setting is present in <filename>postgresql.conf</>
!    or has been received from the <command>postgres</command> command line.
!    (For a role without <literal>LOGIN</> privilege, session defaults have
!    no effect.)
!    Ordinary roles can change their own session defaults.
!    Superusers can change anyone's session defaults.
!    Roles having <literal>CREATEROLE</> privilege can change defaults for
!    non-superuser roles.
!    Certain variables cannot be set this way, or can only be
     set if a superuser issues the command.
    </para>
   </refsect1>
--- 79,96 ----
     password is <literal>MD5</>-encrypted.
    </para>

!   <para>
!    The remaining variants change a role's session default for a
!    specified configuration variable. Whenever the role subsequently
!    starts a new session, the specified value becomes the session
!    default, overriding whatever setting is present in
!    <filename>postgresql.conf</> or has been received from the postgres
!    command line. This only happens at login time, so configuration
!    settings associated with a role to which you've <xref
!    linkend="sql-set-role" endterm="sql-set-role-title"> will be ignored.
!    Superusers can change anyone's session defaults. Roles having
!    <literal>CREATEROLE</> privilege can change defaults for non-superuser
!    roles. Certain variables cannot be set this way, or can only be
     set if a superuser issues the command.
    </para>
   </refsect1>
***************
*** 163,168 ****
--- 162,173 ----
         </para>

         <para>
+         Role-specific variable setting take effect only at login;
+         <xref linkend="sql-set-role" endterm="sql-set-role-title">
+         does not process role-specific variable settings.
+        </para>
+
+        <para>
          See <xref linkend="sql-set" endterm="sql-set-title"> and <xref
          linkend="runtime-config"> for more information about allowed
          parameter names and values.
Index: doc/src/sgml/ref/set_role.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/set_role.sgml,v
retrieving revision 1.6
diff -c -c -r1.6 set_role.sgml
*** doc/src/sgml/ref/set_role.sgml    14 Nov 2008 10:22:47 -0000    1.6
--- doc/src/sgml/ref/set_role.sgml    28 Mar 2009 03:23:57 -0000
***************
*** 92,97 ****
--- 92,104 ----
    </para>

    <para>
+    <command>SET ROLE</> does not process session variables as specified by
+    the role's <xref linkend="sql-alterrole"
+    endterm="sql-alterrole-title"> settings;  this only happens during
+    login.
+   </para>
+
+   <para>
     <command>SET ROLE</> cannot be used within a
     <literal>SECURITY DEFINER</> function.
    </para>

Re: Should SET ROLE inherit config params?

From
Simon Riggs
Date:
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. It is
> > > up to you to solve the problems, which is often possible. 
> > 
> > OK, well, barring the context issues, what do people think of the idea?
> > 
> > What I was thinking was that this would be a setting on the SET ROLE 
> > statement, such as:
> > 
> > SET ROLE special WITH SETTINGS
> > 
> > ... or similar; I'd need to find an existing keyword which works.
> > 
> > I think this bypasses a lot of the issues which Tom raises, but I'd want 
> > to think about the various permutations some more.
> 
> I have added the following TODO:
> 
>     Allow role-specific ALTER ROLE SET variable settings to be processed
>     independently of login; SET ROLE does not process role-specific variable
>     settings
>     
>         * http://archives.postgresql.org/message-id/49B82CD7.20802@agliodbs.com 
> 
> and the attached patch which better documents our current behavior.

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.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



Re: Should SET ROLE inherit config params?

From
Bruce Momjian
Date:
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 that would cause problems. It is
> > > > up to you to solve the problems, which is often possible. 
> > > 
> > > OK, well, barring the context issues, what do people think of the idea?
> > > 
> > > What I was thinking was that this would be a setting on the SET ROLE 
> > > statement, such as:
> > > 
> > > SET ROLE special WITH SETTINGS
> > > 
> > > ... or similar; I'd need to find an existing keyword which works.
> > > 
> > > I think this bypasses a lot of the issues which Tom raises, but I'd want 
> > > to think about the various permutations some more.
> > 
> > I have added the following TODO:
> > 
> >     Allow role-specific ALTER ROLE SET variable settings to be processed
> >     independently of login; SET ROLE does not process role-specific variable
> >     settings
> >     
> >         * http://archives.postgresql.org/message-id/49B82CD7.20802@agliodbs.com 
> > 
> > and the attached patch which better documents our current behavior.
> 
> 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.

Since when does a TODO item squash ideas?  I didn't chisel the TODO item
in stone;  if there is more discussion, someone can update the TODO
item.  Leaving stuff dangle around undocumented is the wrong approach. 
As it is the TODO items is vague.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: Should SET ROLE inherit config params?

From
Josh Berkus
Date:
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.   We need to hash it out 
more after 8.4 goes beta.

--Josh



Re: Should SET ROLE inherit config params?

From
Bruce Momjian
Date:
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 have consensus on the TODO.   We need to hash it out 
> more after 8.4 goes beta.

OK, I am confused, but item removed.  :-|

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +