Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b2edbbd

Browse files
committed
Fix oversight in commit b5415e3.
While rearranging code in tidpath.c, I overlooked the fact that we ought to check restriction_is_securely_promotable when trying to use a join clause as a TID qual. Since tideq itself is leakproof, this wouldn't really allow any interesting leak AFAICT, but it still seems like we had better check it. For consistency with the corresponding logic in indxpath.c, also check rinfo->pseudoconstant. I'm not sure right now that it's possible for that to be set in a join clause, but if it were, a match couldn't be made anyway.
1 parent 60d9979 commit b2edbbd

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

src/backend/optimizer/path/tidpath.c

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -329,9 +329,14 @@ BuildParameterizedTidPaths(PlannerInfo *root, RelOptInfo *rel, List *clauses)
329329
*
330330
* We currently consider only TidEqual join clauses. In principle we
331331
* might find a suitable ScalarArrayOpExpr in the rel's joininfo list,
332-
* but it seems unlikely to be worth checking for.
332+
* but it seems unlikely to be worth expending the cycles to check.
333+
* And we definitely won't find a CurrentOfExpr here. Hence, we don't
334+
* use TidQualFromRestrictInfo; but this must match that function
335+
* otherwise.
333336
*/
334-
if (!IsTidEqualClause(rinfo, rel))
337+
if (rinfo->pseudoconstant ||
338+
!restriction_is_securely_promotable(rinfo, rel) ||
339+
!IsTidEqualClause(rinfo, rel))
335340
continue;
336341

337342
/*

0 commit comments

Comments
 (0)