On Mon, Aug 26, 2013 at 10:50 PM, Stephen Frost <sfr...@snowman.net> wrote: > Martijn, > > * Martijn van Oosterhout (klep...@svana.org) wrote: >> Note, my whole purpose for suggesting something like: >> >> include_auto_conf_file postgresql.auto.conf >> >> is because I want the file location to be configurable. If I put in my >> configuration: >> >> include_auto_conf_file /etc/postgresql/9.4/postgresql.auto.conf > > I'm not following the use-case here. > > Why would it make sense for a file which is entirely managed by PG > automatically to be in /etc? Of course, by the same token you might ask > why it makes sense to let the user pick it at all, which holds some > merit- but I liked your idea because then an admin doesn't have to go > looking for the file but instead knows where it is. Perhaps comments in > the file stating where the auto.conf lives would be sufficient, but > those are too often nuked. :( > >> it better put the options there. And if I comment the line out ALTER >> SYSTEM should stop working. If I put it at the beginning of the config >> then any other option in the file will override it (which we can detect >> and warn about). If I put it at the end of the file, ALTER SYSTEM >> overrides any statically configured options. >> >> And I can imagine hosting providers putting the configuration for >> memory usage, shared library directories and other such options after, >> and options like cpu_cost, enable_merge_join, etc before. That way >> they have fine grained control over which options the user can set and >> which not. > > For my part, I'd honestly rather have the first things found be what's > picked and later things be ignored. If you want it controlled by ALTER > SYSTEM, then don't set it in postgresql.conf. The problem with that is > there's no "bootstrap" mechanism without actually modifying such configs > or making the configs be in auto.conf to begin with, neither of which is > ideal, imv. > > I really hate the idea that someone could configure 'X' in > postgresql.conf and because the auto.conf line is later in the file, > it's able to override the original setting. Does not strike me as > intuitive at all.
This is currently how include mechanism works in postgresql.conf, changing that for this special case can be costly and moreover the specs for this patch were layout from beginning that way. However, we can have some mechanism for appending values (if feasible) as suggested in mail below, after initial patch is done http://www.postgresql.org/message-id/52015414.9060...@cybertec.at With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
