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

Re: prepared statement call fails

From: Markus Schaber <schabios(at)logi-track(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: prepared statement call fails
Date: 2004-12-09 10:20:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Hi, Thomas,

On Mon, 06 Dec 2004 01:04:48 +0100
Thomas Hallgren <thhal(at)mailblocks(dot)com> wrote:

> Oliver Jowett wrote:
> > If you have some particular concerns about how the proposed SP syntax, 
> > whatever it is, is going to break the JDBC driver, by all means raise 
> > them.. but this seems like vague handwaving at the moment.
> I agree that abandoning the current support is a very bad idea. We all 
> have to live with it now. I was surprised to see that it was implemented 
> this way though. My guess is that it's uncommon. It's certanly doable 
> although you will need to dynamically support both mappings once the 
> real SP's arrive and also thoroughly explain some subtle differences in 
> how auto-commit works one way if the underlying code calls a function 
> and another way if it calls a stored procedure.

The question is whether the new SP interface on the server will work for
functions as well (as current functions are semantically a subset of
what stored procedures can do).

This would allow the drivers to always use the new way of calling. As I
heard rumors that the stored procedures will be created by extending the
current function capability, this sounds possible. 

So maybe we should try to influence the server hackers to go into this


markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 z├╝rich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com |

In response to

pgsql-jdbc by date

Next:From: James RobinsonDate: 2004-12-10 18:47:17
Subject: Re: [pgsql-jdbc] Daily digest v1.1401 (1 messages)
Previous:From: Euler Taveira de OliveiraDate: 2004-12-09 02:44:54
Subject: Translation update: pt_BR

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