>"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> > * reset_custom_variable(cusvar); ... set default from postgresql.conf
> > * revoke_custom_variable(READ|MODIFY, cusvar, roleid);
> > * grant_custom_variable(READ|MODIFY, cusvar, roleid);
>
>This seems pointlessly complex. An unprivileged user can only SET the
>value within his own session, and if there are any reasons he shouldn't
>be able to set it, the existing GUC protection categories seem
>sufficient. What's the use-case for all this new mechanism?
>
I would to use custom variables like session variables and I thing so can be
usefull for security definer procedures. But I count with sharing current
code. With described functions I don't need distribute superusers access. I
am not sure, how much code I have to write. Maybe too much. Then I'll prefer
minimalistic version later:
reset_custom_variable(cusvar);
armor custom_variable(cusvar);
I would to test more general solution first
> > Related discussion:
> > http://archives.postgresql.org/pgsql-hackers/2007-03/msg00153.php
>
>Considering no one's bothered to implement that yet, I don't see that
>there's a groundswell of demand for something more complicated.
>
> regards, tom lane
_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
