Martijn,
* Martijn van Oosterhout (kleptog@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.
Thanks,
Stephen
