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