-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sounds like there aren't objections to my requested function,
get_last_returned_oid(). I'm going to work on the function call for
postgres this weekend.
Purpose: Retain the last oid returned (if any) in a variable
associated with the connection on the backend, so the next request to
the backend has access to it. It will be set when an insert or update
is completed, so preparedStatements and stored procedures can use it.
If I'm able to provide patches by Monday, and if it works fine (without causing
general meltdowns :-) would this be able to be in the 7.2 beta, or will it
need to be part of 7.3? (The answer to this question will help me decide on
how much time I should spend on it this weekend.)
> On 23-Aug-2001 Tom Lane wrote:
>>> I assume this OID would be associated with a client connection.
>>> Is this going to work with client side connection pooling?
>>
>> Good point. Will this really get around the original poster's problem??
>
> It must. If transactions are on, any pooling mechanism needs to continue to
> use that connection for the client unti the transaction is done. (Most
> require
> the client to either tell the pool manager the connection is no longer need,
> via a close() call, or a pool-manager specific call, precisely because the
> client needs it to complete the transaction.
>
> My feeling is that if this is a problem, then this method call may need to be
> limited to the transaction context, but I hope that this is not the case.
> Most pool managers (and I'm only speaking about Java here) require some
> activity on the client to give up the connection, either directly or
> indirectly.
Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7hpkHiysnOdCML0URAhPnAJ9z/aWCR88kk60WmZJRalusOYm78ACeLPl7
jRlgOPLcuPd7JCsJy5JomUA=
=ruJB
-----END PGP SIGNATURE-----