Re: BUG #17227: segmentation fault with jsonb_to_recordset
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: bernddorn@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2021-10-13T22:58:10Z
Lists: pgsql-bugs
Attachments
- lateral-function-pullup-bug-wip.patch (text/x-diff) patch
I wrote: > Apparently this idea failed to account for subexpressions pulled up > during later processing. Back to the drawing board. After further study of 7266d0997, it seems we could fix this by the expedient of repeating eval_const_expressions on a function RTE whenever it contains LATERAL references. The code already understood that lateral join aliases were trouble, but it didn't account for the case of subexpressions inserted by subquery pullup (which'd have to have been lateral refs originally). The whole thing makes me itch a little bit, because this logic is assuming that eval_const_expressions is idempotent, something we can't test very well and (AFAIR) are not assuming anywhere else. If somebody made some sub-case not idempotent, we'd not notice until that case got used in a lateral function RTE. That could be a long time, as evidenced by the fact that this bug went undetected for a year since v13 release. However, we had that assumption in the code 7266d0997 replaced too, so this isn't adding any real new risk. I looked briefly at whether the planner's preprocessing steps could be re-ordered to eliminate the need for sometimes reprocessing function RTEs. It looks like it'd be a mess though, a conclusion I think I also reached before committing 7266d0997. Anyway, unless somebody has a better idea, I'll flesh out the attached with a test case and push it. regards, tom lane
Commits
-
Fix planner error with pulling up subquery expressions into function RTEs.
- 4d5f651f1d65 15.0 landed
- fdd6a4d8d90a 13.5 landed
- fd059ac2e461 14.1 landed
-
Allow functions-in-FROM to be pulled up if they reduce to constants.
- 7266d0997dd2 13.0 cited