On 16.06.2011 23:56, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
