Path to PostgreSQL portabiliy

Do we want a Win32 native version of PostgreSQL?

The only reasons *not* to use Cygwin is licensing, installation hassles, and
maybe stability or performance. Therefore, there is no strong technical reason
to defend its removal, only a philosophical one.

The debates on licensing on this list go on for weeks and people feel
passionately about the subject. It seems odd that no one speaks out about the
GNU requirement of cygwin.

If there is a desire to create a PostgreSQL that is "fork" free, then we should
do it now. If now strong desire exists, then we should make an entry in the FAQ
and move on.

If we want to be "portable" (and this should help us with a threading model
later on) we need to cleanup all of the global variables.

PostgreSQL's postmaster should not touch any global variables that are defined
outside something like a pg_global structure and should not touch any static
variables at all. If postmaster initializes a variable that will get cloned on
a fork(), conceptually it is a shared global variable and belongs in
pg_globals. Going all the way and replacing all globals and statics with a
struct should allow threading with TLS. (Thread Local Storage)

Port lib. Regardless where it comes from, the porting code should be a self
contained library, not a list of objects. On Windows, a .DLL can do some things
easier than an application. Also, having a library allows more flexibility as
to how a port is designed.

We should spec out our port interface. This includes file, semaphores, shared
memory, signals/events, process control, IPC, system resources, etc. This will
grow as we re-port to other environments like Windows.

any comments?