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: