Re: PostgreSQL windows native port available

>
> 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 :-(

Yeah. This is unfortunate. We had a right hand recursion in the yacc
parser, and that overflowed the stack when MD5 data was added to the
production .ini's... AND the package list went from 165 to 166 packages.
Who could have known? Anyway I've a fix for it now that I've had a few
minutes to do non-work things, and am about to upload a new snapshot
binary to get folk going again.

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

For setup.exe you could have a small commandline tool to call those
services, and call it in a post-install script. Similar things are done
for other packages in cygwin today.

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

You should rebuild cygwin with a different shared memory area then, to
avoid the -inevitable- shared memory area versioning conflicts that will
arise. Cygwin1.dll needs to share data across process's, and that is
done via a named shared memory area. If your copy of cygwin1.dll is
different to a version the user installs elsewhere, you will have
trouble (unless you've rebuilt cygwin with a different memory area).

I'd suggest that you simply install cygwin in it's usual place, and
forget about it... Anyway, that's a different issue as it is orthogonal
to the installer that is used.

BTW: Jason Tishler may be interested in what you are doing, he maintains
the current Cygwin postgreSQL port.

Rob