From: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal: custom variables management |
Date: | 2007-03-05 20:56:34 |
Message-ID: | BAY20-F18DB18CBF710DF167ABBB9F9840@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>"Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-05 21:03:10 | Re: Bug: Buffer cache is not scan resistant |
Previous Message | A.M. | 2007-03-05 20:55:49 | Re: COMMIT NOWAIT Performance Option |