| 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: | Whole Thread | Raw Message | 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 |