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?
Josh Berkus <josh@agliodbs.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, - 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?!
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
