Re: [BUGS] 7.4 beta 1: SET log_statement=false

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 the snapshot value;

* deny the change if the new value would be greater than the
snapshot value and the current value is less than the snapshot
value;

* new textual values would be matched against a set of acceptable or
unacceptable user values, the status returned by the 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