Thread: Re: C++ with PG 7.4?

> 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? 

Well, it always compiled when it was compiled together with PostgreSQL
as a whole.

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)

Also, the lack of a configure seems to be causing another problem;
a DLLIMPORT symbol that is not being defined automatically.  So, I
now have to add the switch -DDLLIMPORT="" to the command line to
compile any program using libpq++.

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).

For the record, none of these seems to happen with Gentoo Linux.
A colleague of mine has told me about it (trying to convince me
to switch from RedHat), and it seems that these guys (Gentoo Linux)
have a magic management/configuration tool called e-merge that
apparently reads one's mind, and it also reads all the developers'
minds in the world, because my colleague tells me that he simply
typed, at a shell prompt:

# e-merge libpq++

And the system figured out that it also needed postgresql, so
it downloaded the source for both, and compiled both -- on the
right path, and everything compiles without a single switch
required...


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...)

Carlos
--

Carlos Moreno <carlos.moreno@mailinator.com> writes:
>> Finally, please reconsider what you say about libpq++.

> Well, it always compiled when it was compiled together with PostgreSQL
> as a whole.

s/always compiled/sometimes worked on some platforms/.  libpq++ was a
constant portability headache.  This was in fact not libpq++'s fault;
the problem was that C++ was a moving target, both as to the language
itself and the expected standard library.  Perhaps the C++ people
have finally got their act together, but it's too late.  We won't be
buying back into that morass.  Postgres is a C project and we have other
things to do than cope with STL-flavor-of-the-month.

> 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.

Most of the other non-C interfaces have been pushed out of the core
server distribution as well.  The core committee wants to focus on
improving the backend, not on fixing random portability problems in
language-specific client interfaces.  That's not to say that the
client interfaces are not important; it's to say that they are their
own projects and need their own developers and release schedules.
If you want to see libpq++ worked on, go join that project on
gborg.postgresql.org and help work on it.

(FWIW, I'd suggest joining the libpqxx project instead; libpq++ does
not seem to have a critical mass of users/developers anymore.)
        regards, tom lane

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