Re: the parsing of parameters

Поиск
Список
Период
Сортировка
От Karel Zak
Тема Re: the parsing of parameters
Дата
Msg-id 20020510180905.D16905@zf.jcu.cz
обсуждение исходный текст
Ответ на Re: the parsing of parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FW: Cygwin PostgreSQL Information and Suggestions