aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_utilcmd.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-05-07 13:35:10 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-05-07 13:35:10 -0400
commit6572bd55b0a63fe234ec454e7a13f3a373864e9e (patch)
tree23e89c2df4338a718fa2b8399cb19058c4074c1e /src/backend/parser/parse_utilcmd.c
parent09fe9659fd5ea73fb721e270664943cab727354b (diff)
downloadpostgresql-6572bd55b0a63fe234ec454e7a13f3a373864e9e.tar.gz
postgresql-6572bd55b0a63fe234ec454e7a13f3a373864e9e.zip
Prevent RLS filters on ctid from breaking WHERE CURRENT OF <cursor>.
The executor only supports CurrentOfExpr as the sole tidqual of a TidScan plan node. tidpath.c failed to take any particular care about that, but would just take the first ctid equality qual it could find in the target relation's baserestrictinfo list. Originally that was fine because the grammar prevents any other WHERE conditions from being combined with CURRENT OF <cursor>. However, if the relation has RLS visibility policies then those would get included in the list. Should such a policy include a condition on ctid, we'd typically grab the wrong qual and produce a malfunctioning plan. To fix, introduce a simplistic priority ordering scheme for which ctid equality qual to prefer. Real-world cases involving more than one such qual are so rare that it doesn't seem worth going to any great trouble to choose one over another, so I didn't work very hard; but this code could be extended in future if someone thinks differently. It's extremely difficult to think of a reasonable use-case for an RLS restriction involving ctid, and certainly we've heard no field reports of this failure. So this doesn't seem worthy of back-patching, but in the name of cleanliness let's fix it going forward. Patch by me, per report from Robert Haas. Discussion: https://postgr.es/m/3914881.1715038270@sss.pgh.pa.us
Diffstat (limited to 'src/backend/parser/parse_utilcmd.c')
0 files changed, 0 insertions, 0 deletions