Re: How much work is a native Windows application?

Tom Lane wrote:
> With decent packaging, no windows-only user would even know we have
> cygwin in there. The above argument is just plain irrelevant. The real
> point is that we need a nice clean friendly GUI for both installation
> and administration --- and AFAICS that will take about the same amount of
> work to write whether the server requires cygwin internally or not.

Can a cygwin version of PostgreSQL see the native file system, like: C:\My
Database, D:\postgres?

> > From a production stand point, would anyone reading this trust their
> > data to PostgreSQL running on cygwin?
>
> I wouldn't trust my data to *any* database running on a Microsoft OS.

That is a prejudice that is affecting your judgment. Many people do trust
Windows, do I? No, but a lot of people do. People have trusted their businesses
on Windows NT/2K/XP, many are still doing so. We want these people to use
PostgreSQL, so when they see the error in their ways, they have a way out.

> The above argument thus doesn't impress me at all, especially
> when it's being made without offering a shred of evidence that cygwin
> contributes any major degree of instability.

From a software development standpoint, I am VERY uncomfortable with the
technique of a user space program copying its writeable memory to another
process's. It may work until Microsoft changes something with the next version
of IE. What about anti-virus software, cygwin has problems with them, and you
have to have anti-virus software on Windows.

On top of that, the time spent copying the whole process is too long, and it
forces real memory to be allocated and initialized at process startup.

So, the cygwin fork() will cause PostgreSQL to be slower and use more memory
than a native version, and will not co-exist well with anti-virus software.

>
> I am especially unhappy about the prospect of major code revisions
> and development time spent on chasing this rather than improving our
> performance and stability on Unix-type OSes. I agree with the comment
> someone else made: that's just playing Microsoft's game.

Maybe is is playing "Microsoft's Game" but the end result will be a program
that can seriously compete with MSSQL on Windows, and provide a REAL migration
path to UNIX.

Many developers use MSSQL because they "have it" in MSDN, so to them, it is
free. Once they develop something using it, they are tied to Windows. When it
comes time to deploy their pet project, the company has to cough up the price
of the server.

A native, friendly, Win32 PostgreSQL that works the same on Windows as it does
on FreeBSD, Linux, Solaris, etc. Will offer the developer real options away
from Windows.

Also: I don't think it needs to be a major rewrite, no strategy needs to
change, it is basically renaming variables, i.e. my_global_var becomes
pg_globals.my_global_var.

Once that is done, a port writer can do what ever they need to do to get that
structure to the child correctly. As an exercise, I bet if we did this, we
would find bugs which are lurking, as yet unfound.

Besides, the discipline of using a globals structure will improve the code
base. Don't you agree?