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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
