Pavel Stehule wrote:
>
>> "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.
>>
>>
Pavel,
ISTM you are trying to do too much. We need to get the base
functionality, as described by Tom in the thread I referred you to,
working first. Extra stuff could be added later if necessary.
cheers
andrew
