Обсуждение: C++ with PG 7.4?

Hi,

I see that version 7.4 introduces new features in the client
API area -- error codes, for instance.

So, I'm wondering if this will affect the way libpq++ works;
assuming that the SQL's don't use any feature that has changed
with version 7.4, should I expect any difference in code that
uses straightforward things like the following:

PgDatabase db ("host=blah.blah.com user=me dbname=db password=me");

if (db.ConnectionBad())  { .... }

if (db.Exec ("select .... from ....") != PGRES_TUPLES_OK)
{    for (int i = ....  db.Tuples() ....)    {        .... db.GetValue (i, "field_name") .... ;    }
}

if (db.Exec ("insert into ..... ") != PGRES_COMMAND_OK)
{    ....
}


I'm guessing that I would be able to use new features and
new error codes, but if I keep my programs the same (with the
old set of defined constants, etc.), they will work the same?
(again, assuming that the SQL's don't use any feature for
which the behaviour of the backend has changed with ver 7.4)


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

According to a survey you did a while ago, C++ had 2 or
3 times more users than C (off the top of my head -- I
couldn't access the "survey results" page, to check those
numbers).

I must admit to some personal bias in favor of C++, but
still, it's not like C++ is some obscure useless niche
language that only a few weirdos have heard of.

Thoughts, comments?


Thanks,

Carlos
--

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