Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> This (and some other messages in this thread) appears to assume that
> canonicalize_path() turns relative paths into absolute paths, but
> AFAICT, it does not do that.
Ah, fair point --- I'd been assuming that we were applying
canonicalize_path as cleanup for an absolute-ification operation,
but you are right that check_canonical_path does not do that.
Digging around, though, I notice a different motivation.
In assign_pgstat_temp_directory we have
/* check_canonical_path already canonicalized newval for us */
...
tname = guc_malloc(ERROR, strlen(newval) + 12); /* /global.tmp */
sprintf(tname, "%s/global.tmp", newval);
fname = guc_malloc(ERROR, strlen(newval) + 13); /* /global.stat */
sprintf(fname, "%s/global.stat", newval);
and I believe what the comment is on about is that these path derivation
operations are unreliable if newval isn't in canonical form. I seem
to remember for example that in some Windows configurations, mixing
slashes and backslashes doesn't work.
So the real point here is that we could use the user's string unmodified
as long as we only use it exactly as-is, but cases where we derive other
pathnames from it require more work.
Of course, we could leave the GUC string alone and only canonicalize while
forming derived paths, but that seems mighty error-prone. In any case,
just ripping out the check_canonical_path usages without any other mop-up
will break things.
regards, tom lane
