Re: Digital Mars C++ - Clients - Mailing list pgsql-patches

From Stephan Szabo
Subject Re: Digital Mars C++ - Clients
Date
Msg-id 20040708184040.P12046@megazone.bigpanda.com
Whole thread Raw
In response to Re: Digital Mars C++ - Clients  ("Walter" <walter@digitalmars.nospamm.com>)
Responses Re: Digital Mars C++ - Clients
List pgsql-patches
On Thu, 8 Jul 2004, Walter wrote:

>
> "Bruce Momjian" <pgman@candle.pha.pa.us> wrote in message
> news:200407081648.i68GmYd22718@candle.pha.pa.us...
> > Walter wrote:
> > >
> > > "Bruce Momjian" <pgman@candle.pha.pa.us> wrote in message
> > > news:200407052015.i65KFWn13238@candle.pha.pa.us...
> > > >
> > > > Uh, I have never heard of Digital Mars C++.  I see it here though:
> > > >
> > > > http://www.digitalmars.com/
> > > >
> > > > Having never had anyone who uses it, it seems this patch would be
> better
> > > > kept where users of digital Mars could find it, like on their ftp
> > > > server.   I don't think there enough usage of Digital Mars for us to
> > > > adjust our source code at this time.  Do you agree?
> > >
> > > Check out the www.download.com download statistics for DMC++, which is
> just
> > > one portal one can download it from:
> > >
> > > http://www.download.com/sort/3150-2069-0-1-5.html?
> >
> > Looks good, but we have had no requests for it prior to this, and your
> > additions aren't trivial.  You also mentioned it doesn't have popen,
> > meaning it might still be in a state of flux, meaning we would have to
> > continue adjusting our patch --- for a compiler no one has asked about.
>
> Hans Oesterholt-Dijkema, who wrote the patch, is not affiliated with Digital
> Mars. But it's been my experience that any requests for a feature tend to be
> a tiny tip of the iceberg, 99% will just silently walk away from your
> product if it doesn't do X. And you *do* have a request, from someone who
> obviously cared enough to write a non-trivial patch for your product.

Well, to be included in the core tree implies that we have some level of
confidence in the patch and some plan for maintaining it.

On the first, now that I've looked at it.  I'm a little worried about a
couple of pieces.

In the first #ifdef block of the patch, fopen is called with a file whose
name is known to start with a | character, is that really going to work?
Does DMC handle this case in some fashion? Just removing the | isn't going
to be good either since the user presumably asked for an executable after
that |.  This should almost certainly be an error, not an offer to do
something else.

I also think that warnings should be happening at places like \pset pager
since quietly allowing a user to turn on the non-usable pager seems bad to
me.

I'm not sure this is necessarily the right way to approach the patch in
the first place.  It might be better to make a port file with a
popen/pclose implementation (even if it simply acts as a failed open and
does nothing on close). This gets into maintenance issues as well. The
patch as is basically requires that anyone who is modifying psql know and
take care to wrap popen/pclose calls. I'm not sure that it's sufficiently
maintainable at the moment without DMC users around to keep it honest.

pgsql-patches by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Digital Mars C++ - Clients
Next
From: Simon Riggs
Date:
Subject: Re: PITR Archive Recovery plus WIP PITR