On Mon, 26 Oct 2009, Tom Lane wrote:
> BTW, why do we actually need an includedir mechanism for this?
> A simple include of a persistent.conf file seems like it would be
> enough.
Sure, you could do it that way. This patch is more about elegance rather
than being strictly required. The general consensus here seemed to be
that if you're going to start shipping the database with more than one
config file, rather than just hacking those in one at a time it would be
preferrable to grab a directory of them. That seems to be how similar
programs handle things once the number of shipped config files goes from 1
to >1.
One thing this discussion has made me reconsider is whether one of those
files needs to be enforced as always the last one to be parsed, similar to
how postgresql.conf is always the first one. I am slightly concerned that
a future SET PERSISTENT mechanism might update a setting that's later
overriden by a file that just happens to be found later than the mythical
persistent.conf. I'd rather worry about that in the future rather than
burden current design with that detail though. Alvaro already introduced
the init-script way of handling this by suggesting the configuration file
name 00initdb ; using that and 99persistent would seem to be a reasonable
solution that's quite familiar to much of the target audience here. Note
that I don't think that standard requires anything beyond what the
proposed patch already does, processing files in alphabetical order.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD