Re: [COMMITTERS] pgsql: Sigh ... - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [COMMITTERS] pgsql: Sigh ...
Date
Msg-id 481B7094.3060709@dunslane.net
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Sigh ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> Tom Lane wrote:
>>     
>>> Well, maybe the right answer is to take a step back and figure out what
>>> pg_config.h.win32's excuse for living is at all.
>>>       
>
>   
>> Oops, the file is only used by MSVC/BCC, not by MinGW. Sorry for the 
>> mistake about that.
>>     
>
> Well, I'm still wondering why it is an input for MSVC.  If we have a
> configure substitute for MSVC, why isn't it working off pg_config.h.in?
>
> The original idea of pg_config.h.win32 was to support the pre-8.0
> method for building native libpq.dll.  I'd like to see us obsolete that
> method altogether and get rid of pg_config.h.win32.
>   


That makes sense - I'll look at that after I have cleaned up the current 
stuff.

>   
>> However, all the values are hardcoded, so nothing in it should relate to 
>> settings that come from configure, I believe. These should be dealt with 
>> in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).
>>     
>
> FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_SIZE
> into the domain of configurable stuff, too.
>
>             
>   

So I gathered. I'll pick those up as part of the fixes I'm currently coding.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Next
From: Chris Browne
Date:
Subject: Re: Protection from SQL injection