Re: Simplifying unknown-literal handling

On 2005-05-29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew - Supernews <andrew+nonews(at)supernews(dot)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