From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "Freezing" per-role settings |
Date: | 2010-09-07 21:43:12 |
Message-ID: | 1283895792.16127.54.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-09-07 21:47:07 | Re: git: uh-oh |
Previous Message | David E. Wheeler | 2010-09-07 21:12:00 | Re: function_name.parameter_name |