Re: Simplifying unknown-literal handling
От | Andrew - Supernews |
---|---|
Тема | Re: Simplifying unknown-literal handling |
Дата | |
Msg-id | slrnd9km9p.1d3v.andrew+nonews@trinity.supernews.net обсуждение исходный текст |
Ответ на | Simplifying unknown-literal handling (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Simplifying unknown-literal handling
|
Список | pgsql-hackers |
On 2005-05-29, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew - Supernews <andrew+nonews@supernews.com> writes: >> What happens if you send an UNKNOWN from the frontend as binary, and then >> when the desired type is figured out, it turns out to be a bytea? It's >> obviously not acceptable then to truncate after a zero byte. > > This isn't an issue, because if the desired type is something other than > UNKNOWN, we won't be using UNKNOWN's binary input converter. The actual > flow of information in the case you're thinking of is: > > 1. Client sends Parse message with, say, query > INSERT INTO tab(byteacol) VALUES($1); > and the type of param 1 either not specified or given as UNKNOWN. > > 2. Backend infers actual type of param 1 from context as BYTEA. Hrm. I was thinking of the case where the backend can't necessarily do this, but in fact in that case the Parse seems to fail. > Offhand I think the only way you could actually invoke UNKNOWN's binary > input converter is by executing a PREPARE with a parameter position > specifically declared as UNKNOWN, viz Which of course leads to the question of why UNKNOWN has a binary input converter at all... -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
В списке pgsql-hackers по дате отправления: