Re: [BUGS] 7.4 beta 1: SET log_statement=false - Mailing list pgsql-hackers

On Wed, Aug 13, 2003 at 06:05:46PM -0400, Bruce Momjian wrote:
> I tried adding this line:
> 
>     record->session_source < PGC_S_UNPRIVILEGED &&
> 
> and it does allow you to set the variable to false if you have set it to
> true in your session, but it also allows you to set it to false if it is
> set to true in postgresql.conf.   You do this by setting it to 'true'
> _then_ to 'false' in your session.  The reason this works is that there
> is no history in the GUC code to record the value this variable was set
> at various locations.  Once you set it to 'true' in your session, the
> system remembers that, and forgets it was also set to true in
> postgresql.conf, and therefore allows you to set it to false.
The following describes what I would do if I had the controls
on the postgres source code:
I would put the lambda-user protected configuration parameters
under the control of a system similar to what is used for the
{get|set}rlimit system calls. At the begining of a session, a snapshot
of the parameters is taken, it is kept appart from the live
parameters. The snapshot would be used by the parameters controller to
permit or deny a parameter change depending on the snaphot value, the
current value, the desired new value and a set of rules. A rule could
express things like theses:
 * boolean values:
   * deny change if the new value would transition from true to     false and the snapshot value is true;
   * allow change if the new value would transition from true to     false and the snapshot value is false;
   * and any the the negation and/or inverse of both of these rules.
 * numerical values:
   * deny the change if the new value would be less than the snapshot     value and the current value is larger than
thesnapshot value;
 
   * deny the change if the new value would be greater than the     snapshot value and the current value is less than
thesnapshot     value;
 
 * new textual values would be matched against a set of acceptable or   unacceptable user values, the status returned
bythe countroller   would be according the matched set.
 
A scheme like this would allow a tolerance from the user point
of view while fixing limits on what can be done by non-superuser
accounts.
It could also be interesting to tie the parameters set to
transactions: parameters changed while inside a transaction could be
reset to their default or pre-transactions values on a commit or
rollback. This could look like the behavior of the save/restore
postscript operators.
Regards.

-- 
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage