Re: Nested CASE-WHEN scoping

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

In response to

Browse pgsql-hackers by date

  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