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

Re: pgsql: Coerce 'unknown' type parameters to the right type in the

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Coerce 'unknown' type parameters to the right type in the
Date: 2010-08-18 15:03:34
Message-ID: 4C6BF646.1030200@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On 18/08/10 16:57, Tom Lane wrote:
> heikki(at)postgresql(dot)org (Heikki Linnakangas) writes:
>> Log Message:
>> -----------
>> Coerce 'unknown' type parameters to the right type in the fixed-params
>> parse_analyze() function. That case occurs e.g with PL/pgSQL
>> EXECUTE ... USING 'stringconstant'.
>
>> The coercion with a CoerceViaIO node. The result is similar to the coercion
>> via input function performed for unknown constants in coerce_type(),
>> except that this happens at runtime.
>
> Unfortunately, this entirely fails to enforce the rule that an unknown
> Param be coerced the same way everywhere.  You'd need a cleanup pass as
> well, cf check_variable_parameters().

Yeah, you're right. I'll find a way to do the cleanup pass in fixed 
params case too.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2010-08-18 15:05:50
Subject: Re: proposal: tuplestore, tuplesort aggregate functions
Previous:From: Tom LaneDate: 2010-08-18 15:03:23
Subject: Re: git: uh-oh

pgsql-committers by date

Next:From: Tom LaneDate: 2010-08-18 15:21:54
Subject: pgsql: Add missing handling of PlannedStmt.transientPlan in
Previous:From: Tom LaneDate: 2010-08-18 13:57:19
Subject: Re: pgsql: Coerce 'unknown' type parameters to the right type in the

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