Re: libpq++
От | Tom Lane |
---|---|
Тема | Re: libpq++ |
Дата | |
Msg-id | 20210.1011051125@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: libpq++ ("David Joyner" <d4ljoyn@yahoo.com>) |
Список | pgsql-interfaces |
"David Joyner" <d4ljoyn@yahoo.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
В списке pgsql-interfaces по дате отправления: