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

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-jdbc by date

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

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