transactions in libpq++ require new connection? - Mailing list pgsql-interfaces

From George Young
Subject transactions in libpq++ require new connection?
Date
Msg-id 199907081955.PAA21607@ll.mit.edu
Whole thread Raw
Responses Re: [INTERFACES] transactions in libpq++ require new connection?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [INTERFACES] transactions in libpq++ require new connection?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
I am using libpq++ with gcc egcs-2.91.66 (egcs-1.1.2 release) on RH linux 5.1
with Postgres 6.5.  I need to use transactions to maintain consistency
when an application's logical operation actually updates multiple tables.

Currently, the PgTransaction class only has a public constructor which
opens a new connection to the DB, and closes it on commit.  For an application
making many short transactions, in an environment with many active clients,
this seems to be very wasteful of network and cpu resources.  Is there some
reason a PgTransaction could not be constructed from an existing PgDatabase
(or PgConnection)?  Maybe trans should be a lightweight class to avoid
problems with inheriting from PgDatabase and thus having to deal with 
copy/reference-count etc. problems?

I know I can roll my own by just Exec("begin"), etc, but having the
transaction *committed* (not conn closed) in the destructor would be very
handy.


Also, there's no rollback member...


On yet another note, it would be much neater if the c++ interface would use
'string' type for text args and returns.  I'm tired of writing foo.c_str()
everywhere...


Thanks,George

[I'm not too experienced with c++, so I *welcome* any comments/suggestions]


George Young,  Rm. L-204        gry@ll.mit.edu
MIT Lincoln Laboratory
244 Wood St.
Lexington, Massachusetts  02420-9108    (781) 981-2756


pgsql-interfaces by date:

Previous
From: "C.J. Pena"
Date:
Subject: No suitable driver
Next
From: Florian Baumert
Date:
Subject: Postgresql + lo