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

Re: PostgreSQL windows native port available

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: <jm(dot)poure(at)freesurf(dot)fr>, <pgadmin-hackers(at)postgresql(dot)org>
Cc: <robert(dot)collins(at)itdomain(dot)com(dot)au>
Subject: Re: PostgreSQL windows native port available
Date: 2002-05-10 10:50:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr] 
> Sent: 10 May 2002 11:29
> To: Dave Page; pgadmin-hackers(at)postgresql(dot)org
> Cc: robert(dot)collins(at)itdomain(dot)com(dot)au
> Subject: Re: [pgadmin-hackers] PostgreSQL windows native port 
> available
> Le Vendredi 10 Mai 2002 11:21, Dave Page a écrit :
> > I think that a stripped down cygwin version is the (easy) 
> way forward. 
> > I think that's what MySQL do, certainly the cygwin dll is 
> distributed 
> > with it. All that is really required is the rewriting of probably 
> > pg_dumpall, initdb & initlocation  - the rest of the scripts aren't 
> > needed, and a binary-only version would then be easy bar licencing 
> > issues.
> >
> > Writing an installer is easy enough as well...
> Dear Robert,
> Dave Page, pgAdmin2 author (, 
> and I have been 
> discussing for a long time to find a proper way to distribute 
> PostgreSQL 
> using a minimal Cygwin layer. Do not hesitate to correct me 
> if I am wrong :
> Dear Dave,
> Robert Collins wrote me to explain quite a few tricks about 
> Cygwin setup.exe 
> installer:
> 1) Latest CVS Cygwin setup.exe supports scripting. I don't 
> know in what extent 
> installation features are mapped. At least, this means we 
> should try the 
> latest CVS version.
> 2) setup.exe is not needed if you know WHICH packages are 
> required (with no 
> relation to scripting). You simply need to provide path and 
> everything in a 
> proper setup.ini file. Et voilà.
> Setup.exe would be installed by our installer in the proper 
> folder but not 
> used. Users could possibly run setup.exe for upgrades.
> 3) setup.exe supports post-installation scripts. This may 
> allow us to make a 
> minimal PostgreSQL install of Template1, enable a TCP/IP 
> socket, etc... 
> inside a Cygwin package (example : run a bash script or 
> connect locally using 
> SSH to su under postgres user). Otherwize, we could do it 
> manually using an 
> installer script.
> Good news, no?

Hmmm. No offence to Robert, but I do not like the Cygwin installer (from a users pov, not a developers). I always seem to be getting hassled to upgrade it, then when I do, I find it does things like preselect the oldest versions of each package rather than the latest. I ran it the day before yesterday, and it didn't complain that it was out of date for once, but did completely fail to parse the file containing the package info on each of about 5 different mirrors that I tried :-(

It is easily possible to create the required installer using Wise or Installshield (yes I know these aren't free), and both these products could make use of the psqlODBC merge module, and install services & ODBC datasources easily and seamlessly which I suspect is more tricky (if not impossible) in the Cygwin installer (please correct me if I'm wrong).

Installer technologies aside, one of the major reasons for this (and the other discussions on pgsql-hackers) is the wish to 'hide' Cygwin from the PostgreSQL user. We need to make it live in C:\Program Files\PostgreSQL, not have a complete unix style file layout, and generally look like a real Windows application. Cygwin is a great environment for working in and porting software, but now that work is done, PostgreSQL (as an application) should use, and expose the absolute minimum of Cygwin to the user.

Regards, Dave.

pgadmin-hackers by date

Next:From: Robert CollinsDate: 2002-05-10 10:56:06
Subject: Re: PostgreSQL windows native port available
Previous:From: Robert CollinsDate: 2002-05-10 10:50:10
Subject: Re: PostgreSQL windows native port available

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