From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rene Pijlman <rpijlman(at)wanadoo(dot)nl> |
Cc: | Ned Wolpert <ned(dot)wolpert(at)knowledgenet(dot)com>, 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? [was Re: JDBC changes for 7.2... some questions...] |
Date: | 2001-08-23 21:56:51 |
Message-ID: | 16075.998603811@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Rene Pijlman <rpijlman(at)wanadoo(dot)nl> writes:
> On Thu, 23 Aug 2001 14:44:19 -0400, you wrote:
>> seems doable and reasonable to me: whenever an OID is returned
>> to the client in an INSERT or UPDATE command result, also stash it in
>> a static variable that can be picked up by this function.
> What should the semantics be exactly?
Just the same as the command result string.
> How about the multiple INSERT's i've been reading about on
> hackers? ... Only the OID of the last row inserted by the
> statement?
No OID is returned when multiple rows are inserted or updated. I'd say
that should be the semantics of this function, too.
> How about JDBC batchExecute() when it performs multiple
> INSERT/UPDATE's?
By definition, this is a backend function. It cannot know anything of
JDBC.
> 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??
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-08-23 22:01:28 | Re: Remove --enable-syslog? |
Previous Message | Magnus Naeslund(f) | 2001-08-23 21:22:14 | [PATCH] Win32 errno a little bit safer |
From | Date | Subject | |
---|---|---|---|
Next Message | Ned Wolpert | 2001-08-23 22:27:29 | Re: Re: [JDBC] New backend functions? [was Re: JDBC ch |
Previous Message | Rene Pijlman | 2001-08-23 21:37:27 | Re: [PATCHES] JDBC patch for util.Serialize and jdbc2.PreparedStatement |