Thread: Working on native Windows x64 version of PostgreSQL

Hi everyone.

For those who have seen my other thread, I have decided to take the
plunge: I am going to try to get PostgreSQL to compile as a native
Windows x64 application (so that it will be able to interface with x64
DLLs) and I will contribute my changes to the community.

As you know, many of the extra postgres features rely on external
libraries available from gnuwin32, so these must also be converted to
x64 DLLs or they won't work.  I will be starting small, disabling all
these extra features and only trying to build the core functionality.

I plan to work on this in a few stages, submitted as work in progress
patches, because I think this will require a lot of changes.  The
first stage is very simple though; I will be modifying the Perl
scripts in the src/tools/msvc directory to support the x64 compiler.
I am using Microsoft Visual C 2008, but I will try to ensure
everything works with Visual C 2005 (no previous versions have an x64
compiler, so there are only 2 platforms to support).

While this is the simplest change, it may need the most review.  I am
a good C programmer but I barely know Perl.  That has its advantages;
it will ensure I stick to the style currently used since I have no
other habits.

-Ken

On Wed, Jul 2, 2008 at 10:41 PM, Ken Camann <kjcamann@gmail.com> wrote:
> Hi everyone.
>
> For those who have seen my other thread, I have decided to take the
> plunge: I am going to try to get PostgreSQL to compile as a native
> Windows x64 application (so that it will be able to interface with x64
> DLLs) and I will contribute my changes to the community.

:-)

> As you know, many of the extra postgres features rely on external
> libraries available from gnuwin32, so these must also be converted to
> x64 DLLs or they won't work.  I will be starting small, disabling all
> these extra features and only trying to build the core functionality.

That's perfectly reasonable.

> I plan to work on this in a few stages, submitted as work in progress
> patches, because I think this will require a lot of changes.  The
> first stage is very simple though; I will be modifying the Perl
> scripts in the src/tools/msvc directory to support the x64 compiler.
> I am using Microsoft Visual C 2008, but I will try to ensure
> everything works with Visual C 2005 (no previous versions have an x64
> compiler, so there are only 2 platforms to support).

I would suggest generating just VC2k5 project files, and then
modifying the build scripts to upgrade them first if required. We do
something similar with wxWidgets for pgAdmin's use - albeit converting
VC++6 files to 2k5 - using the /upgrade option in vcbuild.exe. I
assume something similar is feasible for 2k5 -> 2k8.

Regards, Dave

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave,
 Just a few comments regarding your pg_dump lock timeout patch (in general I like the concept and agree with adding
it):
 - No validity checking that the argument passed in has anything to dowith a number.  The backend will do this, but it
strikesme as a bitodd to not do any checking at argument processing time.
 
 - You call the argument 'wait time' in the documentation, but 'DELAY'in the command-line help.  I'd recommend using
oneterm and stickingto it.  You're already two lines in the command-line help, you canspell it out as 'WAIT_TIME' or
similar.
 - getTables() uses different variables for each query, and I'minclined to agree with that approach to make following
thecodeeasier.  I'd encourage you to add a new variable for thestatement_timeout query rather than reusing the lockqry
variable.Youcould even offset this by removing the unused delqry variable.
 
 Otherwise, looks good to me.
     Thanks,
    Stephen