Re: Unintegrated stuff in source tree

On Wed, Jul 10, 2002 at 12:18:16AM +0200, Peter Eisentraut wrote:
> There seems to have been an accumulation lately of stuff that was simply
> dumped into the source tree without any sort of integration.  I am
> particularly talking about interfaces/ssl and interfaces/libpqxx.  No
> doubt both of these things are useful in the end, but as they are right
> now they're a headache waiting to happen.
Well, I guess as the author I should comment on the libpqxx side of 
things here.  We decided to drop it into the source tree as-is because 
(1) it's fairly hard to come by the autoconf/automake expertise required 
to make it work from the main source tree's configure script, and (2) not 
all systems or C++ compilers support enough of the Standard to make it 
work, so it ought to remain a separate, optional thing in the beginning.


> Libpqxx:
> 
> * I'm no C++ whizz, but I guarantee that this coding style is not nearly
> as portable as we've tried to make libpq++ be.  Who wants to answer those
> support calls all over again?
Please explain.  I'm sure this is not all portable, but what does coding
style have to do with that?  Sure, Microsoft compilers have a problem
with it, but that's just because they don't support the basic concepts
of the language.  We've tried to fix that, but it's very hard to work 
around a bad compiler.  If your compiler doesn't handle C++, don't try 
to compile C++ with it.  I'd try to run it through more critical
compilers, but according to existing compliance tests, gcc 2.95 through
3.1 happpen to be the best compilers around.

As far as I know, libpqxx relies on only two things: first, the C++
standard, and second, libpq.  If your system doesn't support those,
why bother addressing PostgreSQL from C++ in the first place?


> * What's the deal with libpq++ vs. libpqxx?  Who's going to want to
> explain that to the crowd for the next 5 years?
Frankly, libpq++ was severely broken.  That's a simple story to tell
the crowd in 5 years' time.  As it turned out, there was no way to
fix it except by writing a completely new library.  Use libpq++ if
you must; libpqxx if you have the choice.  If your compiler only
supports C++ as "A Better C" then libpqxx is not for you.  If there
is some other problem with the code--and I can't say I've heard of any
such case in a while--then it ought to be fixed.


> * Bogus Automake stuff -- hurts my eyes. ;-)
Please elaborate.  Like the docs say, the automake stuff was contributed
by external dcvelopers, and I merely tried to edit it.  If you could
just say *what* is so bogus about it, perhaps it could be fixed.  Just
saying that it's bogus and that it hurts your eyes isn't going to help
anyone.  The library has its own automake setup so that it can be
installed separately on systems that support it.  Hopefully someone
will see fit to integrate it into the existing setup at some point.  This
is not proprietary software, after all.


> * Doxygen -- is that going to be a quasi-required tool now?

It comes with docs generated by doxygen.  I don't think that means
that doxygen is "quasi-required" any more than emacs is, just because
some of the text may have been written with it.  If reading HTML is a
problem for you, you have other problems.  Sure, re-generate the docs
with doxygen if you like; you're going to end up with essentially the
same stuff that's bundled with the library.  If you think that's a
useful exercise, you're better off with doxygen.  If you don't, there's
nothing wrong with the way things are.


> * Bonus points for documentation in DocBook format -- but unfortunately
> version 4.1, and unfortunately not integrated with the rest of the
> documentation set.
> 
> * No build integration.

These are on the to-do list, and some are beyond my control so I can't
really address them.  But if you have time to complain about them, 
perhaps you can help fix them as well.  That would be most welcome; I've
essentially been flying blind when writing the docs, mimicking what was
already there.

> * Why are half the text files executable?
Interesting.  Haven't been able to find a single file with this problem
in the libpqxx distribution archive, so they may have been mangled 
somewhere else.  Where did you find the archive with this problem?


> Personally, I'm uneasy about carrying around another interface library
> that appears to have no basis in any sort of standard.

This suggests that either you haven't actually looked at it, or you're
unfamiliar with C++.  The thing about libpqxx is that it makes database
access adhere to standard C++ interfaces.  So saying that it has "no
basis in any sort of standard" is just plain wrong.  In fact, some C++
programmers have found this tremendously useful, and some have chosen
PostgreSQL over competing databases because of this library.

Now if you want to maintain that it doesn't adhere to an existing, set
standard for C++ database access you may have a point--because there
currently are none (unless you count "industry standards" like the 
pitiful crap MFC users are forced to put up with).  But someday there 
will be, and rest assured that they will look very much like the way 
libpqxx does things, because it sticks very closely to existing STL 
standards.  So far, all C++ experts I've presented this to (including
some involved in the C++ standards process, albeit loosely) have been 
very supportive of libpqxx because of this existing lack of standards, 
and the way libpqxx tries to fit things in.

In my opinion, libpqxx is a good replacement for libpq++.  It does more
to conform to standards, it fixes some serious problems with the original
design, and it makes it easy to write solid programs using PostgreSQL.  In 
the future it will probably be extended to cover other databases as well, 
but for now it's a competitive advantage.  Finally, it fills a void in the
C++ world in a way that may someday define new standards.  I don't think
this would be hard to explain to new or existing programmers.


Jeroen