Peter Eisentraut <peter_e@gmx.net> writes:
> Maybe it would be easier if multiple -k options accumulated.
After further thought I'm not very enamored of that concept. We've made
considerable compromises to ensure that every postmaster command-line
option corresponds exactly to some GUC parameter; it does not seem to me
that -k is important enough to deserve an exception.
However, it occurs to me that Murray's original complaint about spaces
in -k pathnames could be dealt with via very narrow changes in
SplitDirectoriesString. That function was modeled on
SplitIdentifierString, with perhaps not enough thought about the
differences between identifiers and pathnames. In particular, I suggest
that there's no need to reject embedded spaces in pathnames, and plenty
of systems on which it's important not to. (Think "Program Files" on
Windows, for instance.) It probably still makes sense to trim leading
and trailing whitespace, but let's allow embedded spaces.
If we did that, the new code would be incompatible with the old only for
paths including commas, leading double quotes, or leading/trailing
whitespace. I submit that all of those cases are pretty uncommon,
especially compared to embedded space.
regards, tom lane