* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@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
Description: Digital signature