On Sun, Dec 21, 2003 at 04:45:08PM -0500, Carlos Moreno wrote:
> Also, are there any plans to re-include C++ client API as
> part of the postgresql package? I don't mean to sound
> ungrateful for everything that PostgreSQL offers, but I do
> believe that removing C++ from the default distribution
> was a great disservice to the community -- partly because
> libpq++ does not even compile without some fine tuning
> (well, programs written with it don't compile -- at least
> on RedHat).
There was some discussion about this, and in my view the upshot was
something like this: it doesn't matter how useful any particular API
may be, the package was just too large. So it's better to leave out
all parts that are not essential (in the strict sense of the word)
from the core product so people don't drown in the base archive.
Having gotten the base archive, users can then pick & download
whatever extras are useful to them--including an API library for
their favourite language, of which they're likely to need only one
or two each.
Both libpq++ and its successor libpqxx were built on top of libpq,
without any special knowledge of or access to its innards. Hence only
libpq is an essential part of the package, whereas libpq++ and libpqxx
are not intimately tied to the database from a technical point of
view. AFAIK the same goes for several (most? all?) other language
bindings.
Finally, please reconsider what you say about libpq++. If it doesn't
compile and there's nobody to do serious maintenance on it, why keep
it bundled? Should an outdated interface be allowed to keep back the
release cycle for the whole database? There isn't even a very tight
coupling, so upgrading the database separately from the library
shouldn't have too great an impact. Changes in error codes are not
something you should need to worry about with a true C++ API; you
won't find a single status return code in libpqxx, for instance.
Jeroen