aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/async.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2023-01-31 11:57:47 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2023-01-31 11:57:47 -0500
commiteae0e20deffb0a73f7cb0e94746f94a1347e71b1 (patch)
tree2cfe6325a33b6a1ef418de180ae07f671236e927 /src/backend/commands/async.c
parent3db72ebcbe20debc6552500ee9ccb4b2007f12f8 (diff)
downloadpostgresql-eae0e20deffb0a73f7cb0e94746f94a1347e71b1.tar.gz
postgresql-eae0e20deffb0a73f7cb0e94746f94a1347e71b1.zip
Remove over-optimistic Assert.
In commit 2489d76c4, I'd thought it'd be safe to assert that a PlaceHolderVar appearing in a scan-level expression has empty nullingrels. However this is not so, as when we determine that a join relation is certainly empty we'll put its targetlist into a Result-with-constant-false-qual node, and nothing is done to adjust the nullingrels of the Vars or PHVs therein. (Arguably, a Result used in this way isn't really a scan-level node, but it certainly isn't an upper node either ...) It's not clear this is worth any close analysis, so let's just take out the faulty Assert. Per report from Robins Tharakan. I added a test case based on his example, just in case somebody tries to tighten this up. Discussion: https://postgr.es/m/CAEP4nAz7Enq3+DEthGG7j27DpuwSRZnW0Nh6jtNh75yErQ_nbA@mail.gmail.com
Diffstat (limited to 'src/backend/commands/async.c')
0 files changed, 0 insertions, 0 deletions