Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters

On 08/05/2013 10:18 PM, Dimitri Fontaine wrote:
> Hi,
>
> I'm now completely lost in the current threads. Is there a single valid
> use case for the feature we're trying to design? Who is the target
> audience of this patch?

wonder about that myself...

>
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> I don't see this as a solution at all. "Mr. Sysadmin, we've given the
>> DBAs a new tool which allows them to override your version-controlled
>> database parameter settings. You can turn it off, though, by using this
>> incredibly complicated, brand-new Event Trigger tool which requires
>> writing lots of SQL code to make work."
>
> Well, given what has been said already and very recently again by Tom,
> it's superuser only and installing a precedent wherein superuser is not
> allowed to use a feature looks like a dead-end. You would have to make a
> case that it's comparable to allow_system_table_mods.
>
> If you believe that revoking ALTER SYSTEM SET privileges to superusers
> isn't going to be accepted, I know of only two other paths to allow you
> to implementing your own policy, including per-GUC policy and
> non-superuser granting of ALTER SYSTEM SET in a controled fashion:
>
> - add per GUC GRANT/REVOKE capabilities to SETTINGs,

realistically I think this is what we "want"(fsvo) for this feature as a
prerequisite, however that also will make it fairly complex to use for
both humans and tools so not sure we would really gain anything...

> - implement the same thing within an Event Trigger.
>
> The former has been talked about lots of time already in the past and
> I'm yet to see any kind of progress made about it despite plenty of user
> support for the feature, the latter requires a shared catalog for global
> object Event Triggers and maybe a flexible Extension that you can manage
> by just dropping a configuration file into the PostgreSQL conf.d.
>
> So when trying to be realistic the answer is "incredibly complicated"
> because it involves a stored procedure to implement the local policy and
> a command to enable the policy, really, I wonder who you're addressing
> there. Certainly not DBA, so that must be sysadmins, who would be better
> off without the feature in the first place if I'm understanding you.
>
> Again, what are we trying to achieve?!

no idea - wondering about that myself...

Stefan