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. > > 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. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers