On Fri, Aug 16, 2013 at 11:12 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas escribió:
>> On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> > A shared catalog which defined which *database* to run the trigger in,
>> > with a way to fire off a new backend worker in that database and tell it
>> > to run the trigger, might be interesting and would deal with the issue
>> > that the trigger would behave differently depending on the database
>> > connected to. That would bring along other issues, of course, but it
>> > seemed an interesting enough idea to mention.
>>
>> Eh, maybe. I'm not sure there's enough use case for that to justify
>> the amount of infrastructure it would require. I'm happy with the
>> recent enhancements to background workers, but there's an awful lot of
>> ground to cover between that and what you're proposing.
>
> Yeah, agreed. There's a lot of infrastructure required for this; it
> seems hard to justify it only to support disabling ALTER SYSTEM.
I think disabling ALTER SYSTEM can be more easily supported if we
choose one of below options:
a. UI into contrib module, people who don't want doesn't include it
b. Have an include file mechanism, so that user can comment the
include in postgresql.conf and disable it.
If I remember correctly, earlier you mentioned that by default auto
file should be parsed after postgresql.conf, but how about reverting
to previous mechanism of "include" such that if the file is mentioned
in include then it will be parsed, else will be ignored. I think this
can be reasonable way to disable.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com