Re: Simplifying unknown-literal handling - Mailing list pgsql-hackers

From Andrew - Supernews
Subject Re: Simplifying unknown-literal handling
Date
Msg-id slrnd9km9p.1d3v.andrew+nonews@trinity.supernews.net
Whole thread Raw
In response to Simplifying unknown-literal handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Simplifying unknown-literal handling
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Simplifying unknown-literal handling
Next
From: Tom Lane
Date:
Subject: Re: Simplifying unknown-literal handling