Pavel Stehule wrote:


"Pavel Stehule" <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq

Reply via email to