Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Sigh ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Date: 2008-05-02 19:44:13
Message-ID: 20832.1209757453@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackerspgsql-patches
Andrew Dunstan <andrew(at)dunslane(dot)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.

> 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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-05-02 19:50:44
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Previous:From: Andrew DunstanDate: 2008-05-02 19:27:05
Subject: Re: [COMMITTERS] pgsql: Sigh ...

pgsql-committers by date

Next:From: Andrew DunstanDate: 2008-05-02 19:50:44
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Previous:From: Andrew DunstanDate: 2008-05-02 19:27:05
Subject: Re: [COMMITTERS] pgsql: Sigh ...

pgsql-patches by date

Next:From: Andrew DunstanDate: 2008-05-02 19:50:44
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Previous:From: Andrew DunstanDate: 2008-05-02 19:27:05
Subject: Re: [COMMITTERS] pgsql: Sigh ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group