aboutsummaryrefslogtreecommitdiff
path: root/src/backend/jit/llvm/llvmjit_inline.cpp
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-10-16 19:18:08 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-10-16 19:18:08 -0400
commit8122160ffb68acb0db740f4f6456fdaaaa577d90 (patch)
tree079a060f096bfeca8dbb46b3fe29bb018d07c53f /src/backend/jit/llvm/llvmjit_inline.cpp
parent18e60712dd852f796bb31a64e8389d92be7cf9c6 (diff)
downloadpostgresql-8122160ffb68acb0db740f4f6456fdaaaa577d90.tar.gz
postgresql-8122160ffb68acb0db740f4f6456fdaaaa577d90.zip
Fix EXPLAIN of SEARCH BREADTH FIRST with a constant initial value.
If the non-recursive term of a SEARCH BREADTH FIRST recursive query has only constants in its target list, the planner will fold the starting RowExpr added by rewrite into a simple Const of type RECORD. The executor doesn't have any problem with that --- but EXPLAIN VERBOSE will encounter the Const as the ultimate source of truth about what the field names of the SET column are, and it didn't know what to do with that. Fortunately, we can pull the identifying typmod out of the Const, in much the same way that record_out would. For reasons that remain a bit obscure to me, this only fails with SEARCH BREADTH FIRST, not SEARCH DEPTH FIRST or CYCLE. But I added regression test cases for both of those options too, just to make sure we don't break it in future. Per bug #17644 from Matthijs van der Vleuten. Back-patch to v14 where these constructs were added. Discussion: https://postgr.es/m/17644-3bd1f3036d6d7a16@postgresql.org
Diffstat (limited to 'src/backend/jit/llvm/llvmjit_inline.cpp')
0 files changed, 0 insertions, 0 deletions