aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2023-02-20 12:06:30 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2023-02-20 12:06:30 -0500
commitc6c3b3bc3de1be016de646403b923c1c8a2521cb (patch)
tree3c9e2d161737785c00ac8791d761d33fbd9cc286 /src/backend/executor/nodeModifyTable.c
parenta316a3bc6d3f57e3fe0d287d11eb4f114388b1b6 (diff)
downloadpostgresql-c6c3b3bc3de1be016de646403b923c1c8a2521cb.tar.gz
postgresql-c6c3b3bc3de1be016de646403b923c1c8a2521cb.zip
Remove gratuitous assumptions about what make_modifytable can see.
For no clearly good reason, make_modifytable assumed that it could not reach its get-the-FDW-info-the-hard-way path in MERGE. It's currently possible to demonstrate that assertion failing, which seems to be due to an upstream planner bug; but there's no good reason to do it like this at all. Let's apply the principle of separation of concerns and make the MERGE check separately, after getting or not getting the fdwroutine pointer. Per report from Alexander Lakhin. No test case, since I think the potential test condition will go away soon. Discussion: https://postgr.es/m/36bee393-b351-16ac-93b2-d46d83637e45@gmail.com
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions