Jeff Davis <pg...@j-davis.com> writes:
> On Tue, 2010-09-07 at 13:30 -0700, David Fetter wrote:
>> Offhand, I'm not thinking of past examples of mutating/disappearing
>> GUC that people would want to freeze, nor of a new GUC that would
>> negate or substantially alter such freezing. What have I missed?
> It just seems like the wrong mechanism.
Yeah, it seems like an ugly and probably basically-wrong solution
to the given problem. And there are a ton of corner cases. For
example, if I "freeze" a user's search_path, what happens if the user
tries to call a function that has a search_path property attached? Does
it matter whether the function is owned by some other userid that maybe
doesn't have a freeze for that value? Similarly, if the user calls a
function that is SECURITY DEFINER to some other role that hasn't got the
freeze flag set, should that function be allowed to change the setting
internally, and if not why not?
For that matter, if user A owns a SECURITY DEFINER function that doesn't
try to set search_path, should a "freeze search_path" applied to user A
somehow result in implicit switches of search_path when that function is
invoked by user B? (Good luck making that one happen without
catastrophic performance degradation, because it would mean looking into
the system catalogs on every function call to see if this
action-at-a-distance should affect this function call.)
And none of this seems to have a lot to do with the original goal,
which IIUC was to make a session read-only, not the activities blamable
on a particular user identity.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
