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