From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgwin32_safestat weirdness |
Date: | 2008-04-16 12:23:06 |
Message-ID: | 4805EFAA.6050705@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander wrote:
> Tom Lane wrote:
>
>> Magnus Hagander <magnus(at)hagander(dot)net> 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.
cheers
andrew
Attachment | Content-Type | Size |
---|---|---|
safestat.patch | text/x-patch | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Radek Strnad | 2008-04-16 12:36:03 | Collation at database level |
Previous Message | Gregory Stark | 2008-04-16 11:12:47 | Re: pg_terminate_backend() issues |