Andrew Dunstan wrote:
> 
> 
> Magnus Hagander wrote:
> > Tom Lane wrote:
> >   
> >> Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>     
> >>> Shouldn't be too hard to do, but I keep thinking it'd be cleaner
> >>> to just not do the redefine when building libpq. It means we'd
> >>> add a define like BUILDING_LIBPQ or something to the libpq
> >>> Makefile, and exclude the redefine if set. 
> >>>       
> >> +1 for that general approach, but let's call the macro something
> >> like UNSAFE_STAT_OKAY.  If the day ever comes that we need safestat
> >> inside libpq, or more likely that we want to exclude it from some
> >> other piece of code, it'll be clearer what to do.
> >>     
> >
> > Hmm. I thought BUILDING_LIBPQ would be the more generic one, since
> > we might want to control other stuff from it. I recall wanting that
> > define at some point in the past, but I can't recall why... :-)
> >
> > But - I'll do it with UNSAFE_STAT_OK if that's what ppl want. And
> > then a simple ifeq() section in libpq Makefile, right?
> >
> > Or we could have libpq define the BUILDING_LIBPQ, and have a header
> > say #ifdef BUILDING_LIBPQ / #define UNSAFE_STAT_OK / #endif....
> > That would certainly be the most flexible, but maybe not the
> > prettiest solution until such time as we actually need it.
> >
> >
> >   
> 
> I think a simple approach is all we need for now - not even sure we
> need an ifeq() section in the makefile.
> 
> Here's a patch, which I'll apply unless there's an objection.

Seems a reasonable step for now, yeah - we can add BUILDING_LIBPQ
sometime in the future if we need it.

However, you patch needs to set the define in the MSVC build as well,
to make sure that the produced libpq.dll is equivalent in functionality.

/Magnus

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to