* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > While I appreciate that there are bootstrap-type issues with this, I
> > really don't like this idea of "later stuff can just override earlier
> > stuff".
>
> > include files and conf.d-style options are for breaking the config up,
> > not to allow you to override options because a file came later than an
> > earlier file. Our particular implementation of config-file reading
> > happens to lend itself to later-definition-wins, but that's really
> > counter-intuitive for anyone unfamiliar with PG, imv.
>
> I don't follow this argument at all. Do you know any software with text
> config files that will act differently from this if the same setting is
> listed twice? "Last one wins" is certainly what I'd expect.
Have you tried having the same mount specified in multiple files in
fstab.d..? Also, aiui (not a big exim fan personally), duplicate
definitions in an exim4/conf.d would result in an error. Playing around
in apache2/sites-enabled, it appears to be "first wins" wrt virtual
hosts.
There's a number of cases where only a single value is being set and
subseqeunt files are 'additive' (eg: ld.so.conf.d), so they don't have
this issue. Similar to that are script directories, which simply run a
set of scripts in the $DIR.d and, as it's the scripts themselves which
are the 'parameters', and being files in a directory, you can't
duplicate them. Others (eg: pam.d) define the file name to be an
enclosing context, again preventing duplication by using the filename
itself.
There are counter-examples also; sysctl.d will replace what's already
been set, so perhaps it simply depends on an individual's experience.
For my part, I'd much prefer an error or warning saying "you've got
duplicate definitions of X" than a last-wins approach, though perhaps
that's just because I like things to be very explicit and clear.
Allowing multiple definitions of the same parameter to be valid isn't
'clear' to me.
Thanks,
Stephen
