Re: Prepared statements and unknown types

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Prepared statements and unknown types
Дата
Msg-id
19247.1285786958@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Prepared statements and unknown types Thom Brown <thom@linux.com>
Re: Prepared statements and unknown types Peter Bex <Peter.Bex@xs4all.nl>
Re: Prepared statements and unknown types Thom Brown <thom@linux.com>
Re: Prepared statements and unknown types Peter Bex <Peter.Bex@xs4all.nl>
Re: Prepared statements and unknown types Tom Lane <tgl@sss.pgh.pa.us>
Re: Prepared statements and unknown types Thom Brown <thom@linux.com>
Re: Prepared statements and unknown types Thom Brown <thom@linux.com>
Re: Prepared statements and unknown types "Igor Neyman" <ineyman@perceptron.com>
Re: Prepared statements and unknown types Thom Brown <thom@linux.com>
Peter Bex  writes:
> On Wed, Sep 29, 2010 at 07:33:53PM +0100, Thom Brown wrote:
>> Okay, I understand what's happening.  But does the planner need to
>> understand the type of literals in the select list if it's not used
>> anywhere else?

> Fields sent back to the client also carry their type with them.
> There's no "unknown" type (and it wouldn't be very useful in any
> case, because how would you go about displaying an unknown type?)

Well, actually there *is* an "unknown" type (OID 705), which is what
will be reported if there's a literal of unresolved type in the SELECT
list.  That's how come you can do

regression=# select 'foo' as meow;
 meow 
------
 foo
(1 row)

However, the issue here is not the output but the input: PREPARE is
complaining that the *input* parameter $1 has no determinate type.
If PREPARE doesn't know it, then the client isn't going to know it
either, and so it would be hard for the client to know what to send
to execute the statement.

			regards, tom lane
В списке pgsql-general по дате отправления
От: sunpeng
Дата:
От: Thom Brown
Дата:
FAQ