> Hmm. This seems to presume that every query will be executed as a
> separate transaction. That's pretty limiting (unless you suppose all
> the queries are read-only).
True, but only at this early stage. There are (at least) two
ways which can be used to provide transaction support:
1) Explicit transaction start/end methods. Eg.
PQXbeginTx(pConn1);
PQXexecute(pConn1, q1);
PQXexecute(pConn1, q2);
PQXexecute(pConn1, q3);
PQXcommitTx(pConn1);
2) Or implicit transaction support. Eg.
PGXquery* q1 = PQXcreateQuery("BEGIN... UPDATE...");
PGXquery* q2 = PQXcreateQuery("UPDATE");
PGXquery* q3 = PQXcreateQuery("INSERT");
PGXquery* q4 = PQXcreateQuery("COMMIT");
In this latter case the PGXconn object would have to inspect the
SQL queries in search of transaction delimiters.
As far as uncommitted transactions go, the PGXconn object has a flag
that indicates whether its currently in a transaction - this flag can
be checked (it currently isn't) upon transitioning to the closed state.
At that point whatever policy governing uncommitted transactions can be
put in place before returning the connection to the pool.
Cheers,
Iker
On Sun, 26 Jan 2003 13:38:02 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Iker Arizmendi <iker@research.att.com> writes:
> > Althought multiple queries can't be executed concurrently they can
> > be queued up by a connection object.
>
> Hmm. This seems to presume that every query will be executed as a
> separate transaction. That's pretty limiting (unless you suppose all
> the queries are read-only).
>
> regards, tom lane
--
Iker Arizmendi
AT&T Labs - Research
Speech and Image Processing Lab
e: iker@research.att.com
w: http://research.att.com
p: 973-360-8516