On Wed, Jun 14, 2000 at 12:35:44PM -0400, Tom Lane wrote:
> "David Reid" <david(at)jetnet(dot)co(dot)uk> writes:
> > OK, agreed (up to a point). So, you want easier maintenance? The ONLY
> > way that I can think of doing it is to have the platform specific IPC
> > stuff in it's own file, hence this patch. The core functions, the ones
> > that have no platform specific code in them, still live in ipc.c but all
> > the functions that are touched by platform code live in either
> > ipc_unix.c or ipc_beos.c.
> This is a step forward from what you had, for sure. I'm not sure if
> the separate-files approach is really good, though, compared to
> a pattern like
> int IPCFunction()
> #ifdef BEOS
> BEOS code
> unix code
> for each function. The thing that scares me about separate files
> is the out-of-sight, out-of-mind problem: if you make a change
> in one file, will you remember to update the corresponding code
> in the other files (if there is any)?
> Comments anyone?
Hrm--we already do this sort of thing for the dynaloader
functions, I assume for much the same reason (very different
interfaces on different systems). It is also somewhat unlikely
that someone modifying the IPC API for one system is going to
be able (or at least willing) to update the functions for other
platforms. On the other hand, basic IPC hasn't changed much
from semaphore/shared memory for quite a while.
Adam Haberlach |"You have to understand that the
adam(at)newsnipple(dot)com | entire 'Net is based on people with
http://www.newsnipple.com/ | too much free time on their hands."
In response to
pgsql-patches by date
|Next:||From: Jan Wieck||Date: 2000-06-14 20:43:39|
|Subject: Re: Big 7.1 open items|
|Previous:||From: Peter Eisentraut||Date: 2000-06-14 16:36:25|
|Subject: Re: Big 7.1 open items |