On 16.06.2011 23:56, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> The complicated part is to ensure that levelsup is always set correctly.
>> At parse time, levelsup is always set to 0, as the syntax doesn't allow
>> referencing upper levels directly. When an SQL function is inlined, any
>> ExpressionParams in the expressions that are substituted for Params need
>> to have their levelsup adjusted, so that it still refers to the right
>> value if there's CASE expressions in the inlined function. Also, when an
>> ExpressionParam is replaced with a Const, the levelsup fields of any
>> other ExpressionParams within the CaseExpr referring to higher levels
>> need to have their levelsup decremented to account for the fact that the
>> CaseExpr doesn't push the expression parameter anymore.
>
> I believe this is an unworkably complex, and almost certainly buggy
> Rube Goldberg device. Even if it manages to work today, it's going to
> be impossible to maintain those levelsup values correctly during
> any sort of expression rearrangement or optimization.
>
> Please take another look at just assigning a PARAM_EXEC parameter per
> Case expression.
I've added this to the TODO list, hopefully someone more skilled with
the planner than me will pick this up...
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com