X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id C7CE4D1B455 for ; Mon, 22 Dec 2003 04:33:31 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 56441-05 for ; Mon, 22 Dec 2003 00:32:42 -0400 (AST) Received: from VL-MO-MR001.ip.videotron.ca (relais.videotron.ca [24.201.245.36]) by svr1.postgresql.org (Postfix) with ESMTP id 97ED5D1B48A for ; Mon, 22 Dec 2003 00:32:41 -0400 (AST) Received: from mailinator.com ([69.70.81.159]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HQA000DL4JDB1@VL-MO-MR001.ip.videotron.ca> for pgsql-interfaces@postgresql.org; Sun, 21 Dec 2003 23:30:49 -0500 (EST) Date: Sun, 21 Dec 2003 22:29:36 -0500 From: Carlos Moreno Subject: Re: C++ with PG 7.4? To: pgsql-interfaces@postgresql.org Message-id: <3FE66520.9040703@mailinator.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200312/46 X-Sequence-Number: 4655 > 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 --