Re: proposal: custom variables management

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/

In response to

Responses

Browse pgsql-hackers by date

  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