Re: Re: [JDBC] New backend functions?

From: Ned Wolpert <ned(dot)wolpert(at)knowledgenet(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rene Pijlman <rpijlman(at)wanadoo(dot)nl>, Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Re: [JDBC] New backend functions?
Date: 2001-08-24 18:12:23
Message-ID: XFMail.20010824111223.ned.wolpert@knowledgenet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

-----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(dot)wolpert(at)knowledgenet(dot)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-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikhail Terekhov 2001-08-24 18:25:34 Re: [HACKERS] Re: WIN32 errno patch
Previous Message Mikheev, Vadim 2001-08-24 17:31:55 RE: [OT] Re: User locks code

Browse pgsql-jdbc by date

  From Date Subject
Next Message Bruce Momjian 2001-08-24 19:10:56 Re: Bug #428: Another security issue with the JDBC driver.
Previous Message pgsql-bugs 2001-08-24 17:20:00 Bug #428: Another security issue with the JDBC driver.