Re: C++ with PG 7.4? - Mailing list pgsql-interfaces

On Sun, Dec 21, 2003 at 10:29:36PM -0500, Carlos Moreno wrote:
> 
> First, it is assumed that the "root" path is /usr/local/pgsql.  The
> first time I tried to install it was with a RedHat box that had the
> postgresql that came with RedHat (installed on /usr directly).  So,
> I had to play with it to make it work.  (when libpq++ was part of
> postgresql, then a default RH box would come with both, and both
> installed on the right/consistent path)
IMHO the problem here is not the unbundling of libpq++, but the
fact that it isn't actively being maintained anymore.  Maintenance
was flagging long before it was unbundled.  I hope there's somebody
who can pick up your patches though.


> None of these happened when libpq++ was part of postgresql.  It's
> not that libpq++'s code is outdated or somewhat incompatible with
> libpq or with postgresql itself -- it seems to be just lack of
> compatibility due to lack of configuration/installation tools
> (nothing that can't be remedy, sure, but it became a twisted
> procedure, that requires extra time and effort for no good reason).
The thing is, libpq++'s code _is_ outdated.  The only thing that
made it easier to use than libpq was the fact that it didn't make
any meaningful distinction between a connection, a transaction,
and a query result.  It's not exception-aware.  Did you realise,
for instance, that until shortly before (I think) libpq++ was 
unbundled, if your program failed with an exception, any 
unfinished transaction still in progress was likely to be quietly
*committed*?

As it turned out, these problems could not be fixed within the 
existing interface.  So the perceived convenience of keeping 
libpq++ bundled would have had its hidden cost, besides just 
slowing down core database development.


> Anyway, coming back to the libpq++ issue... I understand the basic
> rationale behind the decision.  But I still think C++ users are
> being treated very unfairly.  (were the other languages' API's
> removed as well?  I'm not 100% sure, but I think they weren't...)

I think "unfairly" is a strong word.  After all, libpq++ was
replaced by something more modern that's being actively maintained.
So the question wasn't really "should the C++ interface be unbundled?"
The questions that arose were: (1) "should we go to all the trouble of
bundling the new interface, adding bloat to the core archive?" and
(2) "if the new interface isn't included, wouldn't keeping the old
unsupported interface in only lure unsuspecting users into an API 
cul-de-sac?"


Jeroen