Re: proposal for CallableStatements to handle multiple out

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: proposal for CallableStatements to handle multiple out
Date: 2004-06-18 23:40:31
Message-ID: 1087602030.15607.190.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

See Kris's addition.

At this point however I've done some work and realized that most of the
parsing, binding and rewriting of the queries will need to be
encapsulated in two classes, one for regular statements, and one for
callable statements. This will allow me to totally encapsulate the logic
for this inside the CallableStatement implementations, instead of
mucking up the current AbstractJdbc1Statement code.

Dave
On Fri, 2004-06-18 at 19:10, Oliver Jowett wrote:
> Dave Cramer wrote:
> > I'm in the process of writing a patch to get the driver to handle
> > multiple out parms.
> >
> > One mechanism is to create a composite type and a function such as:
> >
> > create type Numeric_Proc_RetType as(it1 numeric(30,15),it2
> > numeric(30,15),it3 numeric(30,15));");
> >
> > create function Numeric_Proc(numeric(30,15),numeric(30,15),
> > numeric(30,15)) returns Numeric_Proc_RetType as 'declare work_ret
> > record; begin select * into work_ret from Numeric_Tab; return work_ret;
> > end;' language 'plpgsql';
> >
> >
> > Are there any problems with this ?
>
> Could you describe the driver side of your proposal?
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
>
> !DSPAM:40d3774e134381905984059!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2004-06-19 00:21:11 Re: proposal for CallableStatements to handle multiple out
Previous Message Oliver Jowett 2004-06-18 23:30:49 Re: [PATCHES] Nested transactions