Re: OK, lets talk portability. - Mailing list pgsql-hackers

From cbbrowne@cbbrowne.com
Subject Re: OK, lets talk portability.
Date
Msg-id 20020507220651.6199138B3F@cbbrowne.com
Whole thread Raw
In response to Re: OK, lets talk portability.  ("Dann Corbit" <DCorbit@connx.com>)
List 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."



pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: OK, lets talk portability.
Next
From: Ryan Bradetich
Date:
Subject: Re: a couple of minor itches: RI Trigger Names, and