Re: libpq++

Okay, I see your point, especially your comments on the object hierarchy.
Because here's the problem (someone must have seen this already):

PgCursor c("host=localhost", "foo");
c.Declare("select * from foo where something=somethingelse");
c.Fetch();
for (int i = 0; i < c.Tuples(); i++)
{   if (something is true)  {    c.ExecCommandOk("update bar set something=something where
something=somethingelse") )     }
}
c.Close();// just rolled back all those updates, but have no idea why!

Thanks
Dave


...
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "David Joyner" <d4ljoyn@yahoo.com>
Cc: <pgsql-interfaces@postgresql.org>
Sent: Monday, January 14, 2002 5:50 PM
Subject: Re: [INTERFACES] libpq++


> "David Joyner" <d4ljoyn@yahoo.com> writes:
> > I recently got the latest source from cvs.  I think there's a bug in
> > pgtransdb.cc.  The pgCommitted flag will never be true after the
implicit
> > BeginTransaction called by creating a PgCursor.
>
> This code is pretty grotty, but that particular issue I don't think is a
> problem.  AFAICS, since a PgTransaction object opens its own database
> connection (yipes!), the only thing ever done in a PgCursor's
> transaction will be to create and read from the cursor.  So whether we
> commit or abort hardly matters.
>
> The real bletcherousness is the overhead of establishing a separate
> connection for each transaction.
>
> Fixing this would probably entail a wholesale redesign of PgCursor,
> PgTransaction, and friends, and would break any applications that are
> using them successfully :-(
>
> There is someone working on a brand-new C++ interface library which
> perhaps will avoid all the mistakes that were made in libpq++.  You
> might want to pitch in with that work.  Check the recent archives
> for (I think) libpqxx.
>
> regards, tom lane


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com