Re: installdir patch for win32

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: "'Tom Lane '" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'''pgsql-patches(at)postgresql(dot)org' ' '" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: installdir patch for win32
Date: 2004-03-26 18:52:44
Message-ID: 200403261852.i2QIqiY24588@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


With most of the Win32 code done, I expected this type of review to see
how we could clean things up further. It would probably be helpful for
folks to poke around and suggest cases where we can generalize or move
things to /port or /backend/port.

---------------------------------------------------------------------------

Claudio Natoli wrote:
>
> > I'm not expecting to see zero ifdefs --- certainly not in the port
> > modules ;-). But Bruce's search, further up in the thread, showed that
> > #ifdef WIN32's are sneaking into a lot of modules that probably
> > shouldn't have any platform dependencies.
>
> For the most part, I disagree (in fact, I was surprised to see how few there
> were). The bulk come from include, bin, interfaces, port... with almost all
> of the first three hits of these existing prior to the port.
>
> With regards to the backend files, a healthy number of these are
> pre-existing, or exist only to include/exclude header files + struct
> members, or simply avoid things that are unix specific.
>
> I recall a few potential culprits lurking in pgstat + postmaster (like the
> pipe() + win32_fork, which could be shipped off to /port), but nothing that
> would substantially impact the number of #ifdefs.
>
>
> > I don't think that's a good sign. We should be working to keep
> > those dependencies localized.
>
> On this, I agree, and if you can point me towards any that you find
> particularly obnoxious (on-list or otherwise), I'll gladly fix them.
> Seriously.
>
> >From my POV, the WIN32 specific areas should be clear and obvious, and
> present no great maintenance challenge. This attitude, however, does not
> extend to some of the EXEC_BACKEND areas, but this is also where we are
> obviously the most hamstrung. As you probably remember, I've already
> undertaken to refactor this section of the backend startup code when the
> dust settles, but some degree of pain will be had here for as long as we
> choose to support platforms without fork().
>
> Cheers,
> Claudio
>
> ---
> Certain disclaimers and policies apply to all email sent from Memetrics.
> For the full text of these disclaimers and policies see
> <a
> href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
> ailpolicy.html</a>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Magnus Hagander 2004-03-26 18:56:41 Re: APC/socket fix (final?)
Previous Message Fabien COELHO 2004-03-26 16:00:53 Re: [NOT] (LIKE|ILIKE) (ANY|ALL) (...)