On Tue, Sep 07, 2010 at 02:43:12PM -0700, Jeff Davis wrote:
> 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?
>
> If you'll allow me to change my argument slightly, it just seems
> chaotic. We'd be introducing the 100+ GUCs all as potential security
> features, and it would (presumably) be up to the user whether they
> considered it a "security feature" or not. I think, in practice, that
> would confuse users about the security of the system, and we'd be more
> reluctant to change GUC behavior because someone, somewhere, might have
> considered it a part of their system's security.
>
> Perhaps someone will assume that they can prevent a user from performing
> joins by disabling and freezing enable_hashjoin/nestloop/mergejoin. Or
> perhaps someone will try to contain a user to a few schemas by freezing
> the search_path. Maybe this is a little far-fetched, but the point is
> that we are quite a ways away from blessing all GUCs with a word like
> "security".
>
> It just seems like the wrong mechanism.
OK :)
> > > It makes more sense to tie it to the role directly, so DDL.
> >
> > There are still arguments for making it DCL-ish, in the sense that
> > it is, at least in this case, viewable as a data control issue.
>
> I would be more open to it if it didn't rely on GUCs at all.
There are two problems at hand here, as I see it: the more general
problem of "freezing" settings for a given role, and the very specific
capability of guaranteeing read-only-ness, which could have large
implications in, for example, data warehousing and replication
systems.
Should we just call them separate problems, look into how to approach
the latter one, and table the former?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
