From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Nested CASE-WHEN scoping |
Date: | 2011-06-17 08:54:51 |
Message-ID: | 4DFB165B.4000004@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16.06.2011 23:56, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2011-06-17 08:57:53 | Re: Re: patch review : Add ability to constrain backend temporary file space |
Previous Message | Florian Pflug | 2011-06-17 08:46:32 | Re: Boolean operators without commutators vs. ALL/ANY |