Whilst cleaning up query-length dependencies, I noticed that our
handling of maximum file pathname lengths is awfully messy.
Different parts of the system rely on no fewer than four different
symbols that they import from several different system header
files (any one of which might not exist on a particular platform):MAXPATHLEN, _POSIX_PATH_MAX, MAX_PATH, PATH_MAX
And on top of that, postgres.h defines MAXPGPATH which is used
by yet other places.
On my system, _POSIX_PATH_MAX = 255, PATH_MAX = 1023, MAXPATHLEN = 1024
(a nearby Linux box is almost but not quite the same) whereas MAXPGPATH
is 128. So there is absolutely no consistency to the pathname length
limits being imposed in different parts of Postgres.
AFAIK, most or all flavors of Unix have kernel limits on the maximum
length of a pathname that will be accepted by the kernel's file-access
calls (it's 1024 on my box). So I don't feel any need to remove
hardwired limits on pathname lengths in favor of indefinitely-expansible
buffers. But it does seem that a little more consistency in the
hardwired limits is called for.
>From the information I have, it seems that the various allegedly-
standard #defines for max pathname length are not too standard,
and I don't think that Postgres internal buffers ought to constrain
path lengths to much less than the kernel limit (so using the
seemingly "standard" _POSIX_PATH_MAX symbol would be a loser).
So my inclination is to define MAXPGPATH as 1024 in config.h, and
remove all uses of the other four symbols in favor of MAXPGPATH.
That would at least provide a single point of tweaking for anyone
who didn't like the value of 1024.
Does anyone have a better idea? Is it worth trying to extract a
system limit on pathlength during configure, rather than leaving
MAXPGPATH as a manual configuration item --- and if so, exactly how
should configure go about it?
regards, tom lane
