Re: "Freezing" per-role settings

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