Skip site navigation (1) Skip section navigation (2)

Re: Simplifying unknown-literal handling

From: Andrew - Supernews <andrew+nonews(at)supernews(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simplifying unknown-literal handling
Date: 2005-05-30 00:07:21
Message-ID: slrnd9km9p.1d3v.andrew+nonews@trinity.supernews.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-05-30 01:13:47
Subject: Re: Simplifying unknown-literal handling
Previous:From: Tom LaneDate: 2005-05-29 21:43:39
Subject: Re: Simplifying unknown-literal handling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group