Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
OK, I see the problem now: we have a CaseTestExpr in the arguments of
the function, which we are unable to reduce to a constant, so it gets
substituted as-is into the body of the function during inlining. And
then it's physically inside the CASE expression that's in the function
body, so it looks like it syntactically belongs to that expression,
which it doesn't. You're probably right that this is impractical to fix
without redesigning the expression representation, and that
CoerceToDomainValue has got a similar issue.
My advice is to not change the parser output representation, though.
What I think you ought to do about this is to have the planner replace
CaseTestExpr and CoerceToDomainValue with PARAM_EXEC Params during
expression preprocessing, and assign suitable Param numbers which it
sticks into the CaseExpr (resp CoerceToDomainExpr) so that those
expressions know which Param slot to fill at runtime. The
const-simplification logic can avoid getting dumber by treating the
cases like known-Param-value cases. I don't think you need to invent
something separate from the PARAM_EXEC infrastructure to handle these.
The main annoyance here is that standalone expressions may now need
Param slots to execute, which will complicate places that need to
evaluate them, but there's probably no way around that (a bespoke
mechanism would complicate those callers just as much, if the number
of value slots it needs is variable, which it will be).
> BTW, i just stumbled into this:
> postgres=# explain verbose SELECT CASE now() WHEN (29+random()::int4)
> THEN 'foo' ELSE 'bar' END;
> ERROR: unexpected CASE WHEN clause: 326
> Looks like ruleutils.c is also not prepared for the case that the
> implicit equality operation gets inlined into something else than an OpExpr.
Grumble ... I thought we'd fixed that ...
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
