Re: the parsing of parameters - Mailing list pgsql-hackers

From Karel Zak
Subject Re: the parsing of parameters
Date
Msg-id 20020510180905.D16905@zf.jcu.cz
Whole thread Raw
In response to Re: the parsing of parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, May 10, 2002 at 11:17:39AM -0400, Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> > Tom Lane wrote:
> >> For this particular application, at least, I do not see the value ...
> >> in fact this seems more likely to break stuff than help.  If the
> >> application does not know what the datatypes are supposed to be,
> >> how is it going to call the prepared statement?
> 
> >     Right  now  using  UNKNOWN_OID in that place leads to a parse
> >     error, what makes me feel absolutely comfortable  that  there
> >     will  be  nobody  using it today. So what kind of "break" are
> >     you talking about?
> 
> What I mean is that I don't see how an application is going to use
> PREPARE/EXECUTE without knowing the data types of the values it
> has to send for EXECUTE.  Inside SPI you could maybe do it, since
> the calling code can examine the modified argtype array, but there
> is no such back-communication channel for PREPARE.  This holds
> for both textual and binary kinds of EXECUTE: how do you know what
> you are supposed to send?
In my original PREPARE/EXECUTE patch (it works in 7.1):
  PREPARE name AS select * from tab where data=$1 USING text;  EXECUTE name USING 'nice text data';
IMHO is possible think about
  EXECUTE name USING 'nice text'::text;
or other cast methods.
       Karel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: FW: Cygwin PostgreSQL Information and Suggestions