Re: [HACKERS] Path-length follies

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Which would lead one to suggest the following as portable as possible way
> out:

> #if defined(PATH_MAX)
> #define MAXPGPATH PATH_MAX
> #else
> #if defined(MAXPATHLEN)
> #define MAXPGPATH MAXPATHLEN
> #else
> #define MAXPGPATH 255 /* because this is the lowest common
> denominator on Posix systems */
> #endif
> #endif

I don't think this would be an improvement. The main problem with it is
that the above code could yield different values for MAXPGPATH *on the
same system* depending on which system include file(s) you had included
before reading config.h. Of course it would be a very bad thing if
different Postgres source files had different ideas about the value of
MAXPGPATH --- it could lead to different interpretations of a struct
layout, for example. (I'm not sure that we actually have any such
structs, but there's obviously potential for trouble.)

If it were really important to have MAXPGPATH exactly equal to the
local filename length limit, I'd be more interested in trying to
configure it just so. One possibility would be to have the configure
script do the equivalent of the above logic once at configure time,
and then put the nailed-down value into config.h. But I can't see
that it's worth the trouble. As long as we are not getting in people's
way with an unreasonably small limit on pathlengths, it doesn't much
matter exactly what the limit is. IMHO anyway.

However, this line of thought does lead to something that maybe we
should change: right now, most of the source files are set up as

#include <all necessary system header files>

#include "postgres.h"

#include "necessary postgres headers"

where config.h is read as part of postgres.h. I wonder whether it's
such a good idea to have different source files reading different
sets of system headers before config.h. Maybe the standard order
ought to be

#include "postgres.h"

#include <all necessary system header files>

#include "necessary postgres headers"

so that config.h is always read in a uniform context.

regards, tom lane