Skip site navigation (1) Skip section navigation (2)

Re: libpq++

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David Joyner" <d4ljoyn(at)yahoo(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: libpq++
Date: 2002-01-14 23:32:05
Message-ID: 20210.1011051125@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfaces
"David Joyner" <d4ljoyn(at)yahoo(dot)com> writes:
> 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!

I'd argue that c.ExecCommandOk() is a bogus operation for a PgCursor
object to be providing... a cursor is not something that should be
able to execute SQL queries unrelated to the cursor.

It would make more sense to me for PgCursor to have open/fetch/close
operations and not much else, and for it to be created with a reference
to an already-open Connection object that provides the conduit for the
cursor commands.  To make this work, probably the Connection object
would have to keep track of whether the backend is inside a transaction
block, and not allow the transaction to be closed as long as there were
live PgCursors attached to it.

			regards, tom lane

In response to

Responses

pgsql-interfaces by date

Next:From: David JoynerDate: 2002-01-15 00:16:41
Subject: Re: libpq++
Previous:From: David JoynerDate: 2002-01-14 23:15:39
Subject: Re: libpq++

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group