Re: Simplifying unknown-literal handling

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: andrew(at)supernews(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simplifying unknown-literal handling
Date: 2005-05-30 01:13:47
Message-ID: 23733.1117415627@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Right, deliberately so, for precisely the reason that we need to know
the correct input converters to use.

>> 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...

Maybe it shouldn't. It does need a binary output converter, to avoid
gratuitous failures in cases like
SELECT 'foo';
so I figure it's probably best to leave the input converter there ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2005-05-30 01:52:55 Re: locks in CREATE TRIGGER, ADD FK
Previous Message Andrew - Supernews 2005-05-30 00:07:21 Re: Simplifying unknown-literal handling