Обсуждение: New user questions re libpq++

I would appreciate some clarification regarding the C++ interface for
postgres.  I am using postgres-6.3.2.  The database lives on a linux box
but the applications I am working on need to run under several different
flavors of Unix (HPUX, Solaris, Linux).

The libpq++ source files all have Feb 13, 1997 listed in their header as
their source control date.  However the man page in the same directory
is dated July 1995.

If anyone could shed some light on any of the following I would be very
grateful:

a) The man page does not seem to match the code at all.  Is there a
newer man page (I noticed a request for documentation in the archives
but did not find a response).

b) Do I have the most up to date version of the pq++ library.

c) The header file c.h for libpq (which are included by libpq++) is
interacting with the version of the GNU standard stream library which I
have (gnu 2.8.x and egcs 1.0.2). The problem seems to be the prototype
for the function char* form(...). Both stream.h and c.h prototype a
function of with the same name and arguments.  Is this a known problem,
and is there a fix?  (it looks like it would be fairly simple for me to
change libpg's form to some other name, but I'd rather use a standard
fix if I can).

d) I have never looked at ODBC (and am not 100% sure I know what it is).
The applications I am working on are fairly straightforward. They
currently use at flat table style database (gdbm).  I am looking for the
best interface to use to move these applications to postgres (where best
is a function which maximizes reliability and minimizes my learning
curve). The interface I use needs to be able to run on host different
from the one running postgres.

In the combined wisdom of the group should I (1) forget libpq++ and
simply use libpq (2) use libpg++ or (3) take the trouble to install and
learn ODBC?

Thanks very to everyone for their time.
Phil
promig@acm.org

Phil Romig <promig@acm.org> writes:
> I would appreciate some clarification regarding the C++ interface for
> postgres.  I am using postgres-6.3.2.

> a) The man page does not seem to match the code at all.  Is there a
> newer man page (I noticed a request for documentation in the archives
> but did not find a response).

Wouldn't surprise me --- libpq++ doesn't seem to have anyone taking
responsibility for it, so the documentation is probably suffering from
software rot.  Reading the code is probably the best bet (although
if you cared to update the docs as you read, that would be much
appreciated...).  There isn't *that* much to libpq++, it's just a rather
thin object-style wrapper for libpq.  So you should definitely read the
libpq docs first to make sense of the code.

> b) Do I have the most up to date version of the pq++ library.

You have the latest official release.  There are some bug fixes in
the current pre-6.4 beta releases, so you might care to try running
a beta copy instead.

> c) The header file c.h for libpq (which are included by libpq++) is
> interacting with the version of the GNU standard stream library which I
> have (gnu 2.8.x and egcs 1.0.2). The problem seems to be the prototype
> for the function char* form(...). Both stream.h and c.h prototype a
> function of with the same name and arguments.  Is this a known problem,
> and is there a fix?

As of the 6.4 beta releases, libpq has been cleaned up so that including
libpq-fe.h doesn't import quite as much cruft; in particular c.h is not
included anymore.  I think that that might fix your problem?  I haven't
really tried to use libpq++ personally so can't be sure.  If you try it
please report back.

> In the combined wisdom of the group should I (1) forget libpq++ and
> simply use libpq (2) use libpg++ or (3) take the trouble to install and
> learn ODBC?

(1) libpq++ is kind of an orphan right now, so you may (will) find rough
spots that need to be sanded off.  If you are willing to fix problems
you come across then the Postgres group would gladly take back the
changes.  If you don't want to get involved then it's hard to recommend
using libpq++.

(1a) Using libpq directly from C++ code is a very viable alternative.
I have several large apps that do it.  (Well, actually, I use a couple
of homegrown C++ classes as wrappers on PGconn and PGresult, just to
have a more C++-like syntax for the function calls, but basically it's
libpq's API.)

(2) libpg++ ?  I'm afraid I'm not sure what that is.  Some outside
interface to PGSQL maybe, or just a typo?  If it's some code I haven't
heard about, I'd be interested to know more.

(3) Haven't used ODBC so can't comment on this option.

            regards, tom lane

>
> > a) The man page does not seem to match the code at all.  Is there a
> > newer man page (I noticed a request for documentation in the archives
> > but did not find a response).
>
> Wouldn't surprise me --- libpq++ doesn't seem to have anyone taking
> responsibility for it, so the documentation is probably suffering from
> software rot.  Reading the code is probably the best bet (although
> if you cared to update the docs as you read, that would be much
> appreciated...).  There isn't *that* much to libpq++, it's just a rather
> thin object-style wrapper for libpq.  So you should definitely read the
> libpq docs first to make sense of the code.

After digging into the header files I found the biggest problem with the
documentation is simply typographical.  It looks like sometime after the
docs were written they changed the capitalization scheme.  However they
also changed the class hierarchy and any change to the doc should probably
reflect that.  If I get comfortable enough with the code to fix the doc's
I would be happy to do it.

> > c) The header file c.h for libpq (which are included by libpq++) is
> > interacting with the version of the GNU standard stream library which I
> > have (gnu 2.8.x and egcs 1.0.2).
>
> As of the 6.4 beta releases, libpq has been cleaned up so that including
> libpq-fe.h doesn't import quite as much cruft; in particular c.h is not
> included anymore.  I think that that might fix your problem?  I haven't
> really tried to use libpq++ personally so can't be sure.  If you try it
> please report back.

I did install the 6.4 beta and it did fix the problem, thanks.  There is a
new problem with the c.h file, but I will get to that in a minute.

> (2) libpg++ ?  I'm afraid I'm not sure what that is.  Some outside
> interface to PGSQL maybe, or just a typo?  If it's some code I haven't
> heard about, I'd be interested to know more.

Typo, sorry.  For some reason I am incapable of typing a p then a q.


The installation of 6.4 beta went well.  However I have found one small
problem when using the new c.h header file and a ANSI standard C++ compiler
(not a big suprise, the official ANSI standard for C++ is only about 2 months
old). Briefly, the new standard does not require that C++ compiler define
__STDC__, but rather __STDCPP__.  Hence any code currently protected with
#ifdef __STDC__ needs to be looked at.

I did patch my version of c.h and would be happy to submit my change back
to the developers.  Should I

1) Post the change here.
2) Subscribe to the developers list and post it there.
3) Post it via the bug form from the postgres web page.
4) Other

Thanks for your help
Phil
promig@acm.org

Phil Romig <romig@bierstadt.unl.edu> writes:
> I did patch my version of c.h and would be happy to submit my change back
> to the developers.  Should I
> 1) Post the change here.
> 2) Subscribe to the developers list and post it there.
> 3) Post it via the bug form from the postgres web page.
> 4) Other

When you have a specific patch to propose, the best way is to send
an explanation and a context diff to the patches list
(pgsql-patches@postgreSQL.org).  The other mailing lists aren't the
most appropriate places for patches.  The bug form is for reporting
bugs that you don't have a fix for...

            regards, tom lane

On 18-Oct-98 Phil Romig wrote:
> I would appreciate some clarification regarding the C++ interface for
> postgres.  I am using postgres-6.3.2.  The database lives on a linux box
> but the applications I am working on need to run under several different
> flavors of Unix (HPUX, Solaris, Linux).
>
> The libpq++ source files all have Feb 13, 1997 listed in their header as
> their source control date.  However the man page in the same directory
> is dated July 1995.
>
> If anyone could shed some light on any of the following I would be very
> grateful:
>
> a) The man page does not seem to match the code at all.  Is there a
> newer man page (I noticed a request for documentation in the archives
> but did not find a response).

        This is true of most PostgreSQL documentation, IMHO.

> b) Do I have the most up to date version of the pq++ library.
>
> c) The header file c.h for libpq (which are included by libpq++) is
> interacting with the version of the GNU standard stream library which I
> have (gnu 2.8.x and egcs 1.0.2). The problem seems to be the prototype
> for the function char* form(...). Both stream.h and c.h prototype a
> function of with the same name and arguments.  Is this a known problem,
> and is there a fix?  (it looks like it would be fairly simple for me to
> change libpg's form to some other name, but I'd rather use a standard
> fix if I can).
>
> d) I have never looked at ODBC (and am not 100% sure I know what it is).
> The applications I am working on are fairly straightforward. They
> currently use at flat table style database (gdbm).  I am looking for the
> best interface to use to move these applications to postgres (where best
> is a function which maximizes reliability and minimizes my learning
> curve). The interface I use needs to be able to run on host different
> from the one running postgres.

        Based solely on the opinion of others whose opinions have
proven worth listening to, I'd advise not to bother using ODBC unless
you're looking for PC compatibility. ODBC has a reputation for requiring
more CPU and memory than other competing technologies. I've found the
PostgreSQL TCP-based interface to be pretty handy, but I don't have
any MSDOS/Windows client, either. You only mentioned flavors of Unix
OS in your description of your project, so I wouldn't think you'd care
about Windows apps, either.

> In the combined wisdom of the group should I (1) forget libpq++ and
> simply use libpq (2) use libpg++ or (3) take the trouble to install and
> learn ODBC?

        Have you looked at using embedded SQL for C? It's not a C++
interface, but it's sorta like standard embedded SQL, so it would
probably be easy to port to other databases. I recently ported some
Informix ESQL/C-based  libraries of mine over to the PostgreSQL ESQL/C
without too much trouble. The major annoyances with the current version
, which is called "ecpg", and came with PostgreSQL 6.3.2, are:

        * an almost total lack of usefuldocumentation. This can be
gotten around by using ESQL documentation for other products, like
Informix ESQL/C.

        * no macro statement (i.e., an "EXEC SQL DEFINE"). This has been
added in the new version, if I've read the newsgroup archives correctly.

        ecpg is described somewhere on the www.postgresql.org site.

        If you're looking for something more graphical, there's also a
Tcl/Tk library for PostgreSQL called "libpgtcl". There's a good example
of programming in this interface called "pgaccess". While Tcl/Tk is
interpreted, I've found it often performs as well as compiled Motif
applications in similar circumstances. I've run pgaccess on various
Unix systems (Sun, HP, Linux) to access databases on Linux and HP hosts.
Hooks have been provided in Tcl to allow the use of compiled libraries,
so if you already have C++ code that you want to use in your new
application, you might be able to graft them into it through this
interface.

----------------------------------
Date: 20-Oct-98  Time: 13:05:56

Craig Orsinger                  (email: <orsingerc@epg.lewis.army.mil>)
Logicon RDA
Bldg. 8B28                      "Just another megalomaniac with ideas above his
6th & F Streets                 station. The Universe is full of them."
Ft. Lewis, WA   98433                   - The Doctor
----------------------------------

Just another viewpoint...

Craig wrote...

> On 18-Oct-98 Phil Romig wrote:
> > I would appreciate some clarification regarding the C++ interface for
> > postgres.  I am using postgres-6.3.2.  The database lives on a linux box
> > but the applications I am working on need to run under several different
> > flavors of Unix (HPUX, Solaris, Linux).
> >
[snip]
>
>         Based solely on the opinion of others whose opinions have
> proven worth listening to, I'd advise not to bother using ODBC unless
> you're looking for PC compatibility. ODBC has a reputation for requiring
> more CPU and memory than other competing technologies. I've found the
> PostgreSQL TCP-based interface to be pretty handy, but I don't have
> any MSDOS/Windows client, either. You only mentioned flavors of Unix
> OS in your description of your project, so I wouldn't think you'd care
> about Windows apps, either.
>

It is kind of complex.  It does work for Unix systems.  I've got
ApplixWare talking to PostgreSQL using an ODBC interface.   But I'm
not sure I'd like to write software that uses the ODBC calls.

>
>         If you're looking for something more graphical, there's also a
> Tcl/Tk library for PostgreSQL called "libpgtcl". There's a good example
> of programming in this interface called "pgaccess". While Tcl/Tk is
> interpreted, I've found it often performs as well as compiled Motif
> applications in similar circumstances. I've run pgaccess on various
> Unix systems (Sun, HP, Linux) to access databases on Linux and HP hosts.
> Hooks have been provided in Tcl to allow the use of compiled libraries,
> so if you already have C++ code that you want to use in your new
> application, you might be able to graft them into it through this
> interface.
>

Another choice would be Perl.  I do a *LOT* of Tcl programming, but I still
often recommend Perl for things like this.  Why?

    1) I think Perl compiles easier on more machines that TCL.

    2) The DBI/DBD Perl databse interface is (to as large an extent
           possible) database-independent (That's the DBI part).  I have
       had 0 problems with either the PostgreSQL and Oracle interfaces.

    3) Perl also has an RPC based DBD module that lets you access remote
           databases without having to buy, say, SQL*NET for Oracle. Of course
           the PostgreSQL client side library is free, so in this case the
       point is moot.

    4) Perl is slightly better accepted by Suits.

Either Perl or TCL may be a good choice, so check them both out.

-- cary