Andres Freund <and...@anarazel.de> writes: > On 2017-03-15 20:09:03 -0400, Tom Lane wrote: >> That scares me quite a bit, because it smells exactly like the sort of >> premature optimization that bit us on the rear in CVE-2016-5423 (cf commit >> f0c7b789a).
> I don't think there's a danger similar to f0c7b789a here, because the > "caller" (i.e. the node that needs the expression's result) expects > resvalue/null to be overwritten. Yeah, that's what I thought when I wrote the broken code in ExecEvalCase, too. It was wrong. Basically you've got to be sure that no aliasing can occur, and I think the only way to be safe about that is to have a very clear rule about where results are allowed to get returned to, preferably one that doesn't ever re-use the same target. (I think the repeated use of the same subexpression result address for the arms of an AND or OR is okay, but it would be a good idea to have a clear statement of why.) The thing that actually made the ExecEvalCase code into a bug was that we were using ExprContext-level fields to store the current caseValue, allowing aliasing to occur across nested CASEs. I think that in this implementation, it ought to be possible to get rid of ExprContext.caseValue_datum et al altogether, in favor of some storage location that's private to each CASE expression. I'm a bit disappointed that that doesn't seem to have happened. Eventually, I would also like to find a way to remove the restriction imposed by the other part of f0c7b789a, ie that we can't inline a SQL function when that would result in intermixing two levels of CASE expression. An implementation along the lines of what I've sketched above could handle that easily enough, as long as we could identify which nested level of CASE a particular CaseTestExpr belongs to. I don't know how to do that offhand, but it seems like it ought to be soluble if we put a bit of thought into it. 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