Path to PostgreSQL portabiliy - Mailing list pgsql-hackers

From Lee Kindness
Subject Path to PostgreSQL portabiliy
Date
Msg-id 15577.17903.180863.251963@kelvin.csl.co.uk
Whole thread Raw
In response to Path to PostgreSQL portabiliy  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
mlw writes:> [ snip ]> Port lib. Regardless where it comes from, the porting code should be a self> contained library,
nota list of objects. On Windows, a .DLL can do some things> easier than an application. Also, having a library allows
moreflexibility 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
toother environments like Windows.
 

In other words ignore the POSIX capabilities/features of the largely
compatible Unix systems and invent a layer over them to aid porting to
more POSIXly challenged systems (i.e. Windows)...

Seems like the wrong way of doing things - change the majority to aid
the minority! Doesn't the current method of relying on POSIX
compatability layers on Windows make more sense?

Even if such a 'port library' was the way forward, it should be just
using an existing one, i.e. Apache [A]PR. No use replicating all the
effort!

Looking into APR got me back to thinking about a PostgreSQL and mmap -
what's the stance on it? Useable? In the archives someone was looking
into mmap use for WAL, but this hasn't reappeared for 7.3... I'm
thinking about using mmap for COPY FROM...

Lee.


pgsql-hackers by date:

Previous
From: "Joel Burton"
Date:
Subject: Re: Path to PostgreSQL portabiliy
Next
From: Manfred Koizar
Date:
Subject: Re: Number of attributes in HeapTupleHeader