Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Not really. I'd suggest making the callers do something like >>> >>> #ifdef HAVE_FNMATCH >>> #include <fnmatch.h> >>> #else >>> #include "port/pg_fnmatch.h" >>> #endif > >> How's that actually different from the >> #ifdef HAVE_FNMATCH >> #include <fnmatch.h> <-- happens in fe-secure.c >> #else >> #define .... <-- happens in port.h >> #endif > > What's bothering me is that port.h gets included *everywhere*, and > might perhaps conflict with some indirect or accidental inclusion > of <fnmatch.h>. > > It would also allow someone to forget the > #ifdef HAVE_FNMATCH > #include <fnmatch.h> > #endif > part and have it still work, if they were testing on a broken platform. > It's better that both inclusions appear together instead of having the > alternative code paths effectively appear in two unrelated files.
Ok, I see your argument now. AFAICS, we're not doing this for any other functions though - or am I too tired and just looking in the wrong place? Or is that because they're just function definitions and not #defines? (I want to be sure to stick whatever new file there is in the same place..) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
