Path to PostgreSQL portabiliy

From: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>
To: mlw <markw(at)mohawksoft(dot)com>
Cc: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Path to PostgreSQL portabiliy
Date: 2002-05-08 15:36:15
Message-ID: 15577.17903.180863.251963@kelvin.csl.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

mlw writes:
> [ snip ]
> 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.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-05-08 15:37:02 Re: Path to PostgreSQL portabiliy
Previous Message Manfred Koizar 2002-05-08 15:29:38 Re: Number of attributes in HeapTupleHeader