pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedC++ with PG 7.4?
5+ messages / 3 participants
[nested] [flat]
* C++ with PG 7.4?
@ 2003-12-21 21:45 Carlos Moreno <carlos.moreno@mailinator.com>
0 siblings, 1 reply; 5+ messages in thread
From: Carlos Moreno @ 2003-12-21 21:45 UTC (permalink / raw)
To: pgsql-interfaces
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
--
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C++ with PG 7.4?
@ 2003-12-22 00:48 Jeroen T. Vermeulen <jtv@xs4all.nl>
parent: Carlos Moreno <carlos.moreno@mailinator.com>
0 siblings, 0 replies; 5+ messages in thread
From: Jeroen T. Vermeulen @ 2003-12-22 00:48 UTC (permalink / raw)
To: Carlos Moreno <carlos.moreno@mailinator.com>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C++ with PG 7.4?
@ 2003-12-22 03:29 Carlos Moreno <carlos.moreno@mailinator.com>
0 siblings, 2 replies; 5+ messages in thread
From: Carlos Moreno @ 2003-12-22 03:29 UTC (permalink / raw)
To: pgsql-interfaces
> 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
--
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C++ with PG 7.4?
@ 2003-12-22 05:04 Tom Lane <tgl@sss.pgh.pa.us>
parent: Carlos Moreno <carlos.moreno@mailinator.com>
1 sibling, 0 replies; 5+ messages in thread
From: Tom Lane @ 2003-12-22 05:04 UTC (permalink / raw)
To: Carlos Moreno <carlos.moreno@mailinator.com>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C++ with PG 7.4?
@ 2003-12-22 14:24 Jeroen T. Vermeulen <jtv@xs4all.nl>
parent: Carlos Moreno <carlos.moreno@mailinator.com>
1 sibling, 0 replies; 5+ messages in thread
From: Jeroen T. Vermeulen @ 2003-12-22 14:24 UTC (permalink / raw)
To: Carlos Moreno <carlos.moreno@mailinator.com>; +Cc: 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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2003-12-22 14:24 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-12-21 21:45 C++ with PG 7.4? Carlos Moreno <carlos.moreno@mailinator.com>
2003-12-22 00:48 ` Jeroen T. Vermeulen <jtv@xs4all.nl>
2003-12-22 03:29 Re: C++ with PG 7.4? Carlos Moreno <carlos.moreno@mailinator.com>
2003-12-22 05:04 ` Re: C++ with PG 7.4? Tom Lane <tgl@sss.pgh.pa.us>
2003-12-22 14:24 ` Re: C++ with PG 7.4? Jeroen T. Vermeulen <jtv@xs4all.nl>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox