Re: OK, lets talk portability.

From: cbbrowne(at)cbbrowne(dot)com
To: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, cbbrowne(at)cbbrowne(dot)com
Subject: Re: OK, lets talk portability.
Date: 2002-05-07 22:06:51
Message-ID: 20020507220651.6199138B3F@cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Translation from UNIX to Win32:
> http://www.byte.com/art/9410/sec14/art3.htm

The problem here is that the strategies getting sold aren't "How Do We Make it
Portable?" ones, but rather "How do we port it to Windows, and throw away the
Unix version?"

The "neat technologies" are _not_ portability ventures, but rather porting
ventures, one way trips down the "Richmond Highway."

To have something that will truly be portable, it can't directly use fork().
It has to use [something else] which gets translated at compile time to
fork(), on Unix, and presumably to CreateProcess() on Windows.

It's probably possible; I doubt it's simple nor much of an improvement.

And it begs the question: Is it really greatly advantageous to invoke a lot of
"breakage" on existing code just to get the engine to work on Windows, when
"Windows 2004" will probably have some built-in DBMS technology that tries to
kill off _all_ Windows-based DBMSes that don't come from Microsoft?
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/rdbms.html
It is better to be a smart ass than a dumb ass.

--
(concatenate 'string "chris" "@cbbrowne.com")
http://www.cbbrowne.com/info/linuxdistributions.html
"The primary difference between computer salesmen and used car
salesmen is that used car salesmen know when they're lying to you."

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jade 2002-05-07 22:36:30 postgresql 7.1 file descriptor
Previous Message Dann Corbit 2002-05-07 22:04:30 Re: OK, lets talk portability.