- Notifications
You must be signed in to change notification settings - Fork28
Commitc82d4e6
committed
Fix mishandling of tSRFs at different nesting levels.
Given a targetlist like "srf(x), f(srf(x))", split_pathtarget_at_srfs()decided that it needed two levels of ProjectSet nodes, failing to noticethat the two SRF calls are textually equal(). Because of that, setrefs.cwould convert the upper ProjectSet's tlist to "Var1, f(Var1)" (where Var1represents a reference to the srf(x) output of the lower ProjectSet).This triggered an assertion in nodeProjectSet.c complaining that it foundno SRFs to evaluate, as reported by Erik Rijkers.What we want in such a case is to evaluate srf(x) only once and use a plainResult node to compute "Var1, f(Var1)"; that gives results similar to whatprevious versions produced, whereas allowing srf(x) to be evaluated againin an upper ProjectSet would square the number of rows emitted.Furthermore, even if the SRF calls aren't textually identical, we want themto be evaluated in lockstep, because that's what happened in the oldimplementation. But split_pathtarget_at_srfs() got this completely wrong,using two levels of ProjectSet for a case like "srf(x), f(srf(y))".Hence, rewrite split_pathtarget_at_srfs() from the ground up so that itgroups SRFs according to the depth of nesting of SRFs in their arguments.This is pretty much how we envisioned that working originally, but I blewit when it came to implementation.In passing, optimize the case of target == input_target, which I noticedis not only possible but quite common.Discussion:https://postgr.es/m/dcbd2853c05d22088766553d60dc78c6@xs4all.nl1 parentecb814b commitc82d4e6
File tree
4 files changed
+361
-93
lines changed- src
- backend/optimizer/util
- test/regress
- expected
- sql
4 files changed
+361
-93
lines changed0 commit comments
Comments
(0)