Fix another oversight in CustomScan patch.

execCurrent.c's search_plan_tree() must recognize a CustomScan on the
target relation.  This would only be helpful for custom providers that
support CurrentOfExpr quals, which is probably a bit far-fetched, but
it's not impossible I think.  But even without assuming that, we need
to recognize a scanned-relation match so that we will properly throw
error if the desired relation is being scanned with both a CustomScan
and a regular scan (ie, self-join).

Also recognize ForeignScanState for similar reasons.  Supporting WHERE
CURRENT OF on a foreign table is probably even more far-fetched than
it is for custom scans, but I think in principle you could do it with
postgres_fdw (or another FDW that supports the ctid column).  This
would be a back-patchable bug fix if existing FDWs handled CurrentOfExpr,
but I doubt any do so I won't bother back-patching.

diff --git a/src/backend/executor/execCurrent.c b/src/backend/executor/execCurrent.c
index 7ff3e1ece1a3a0cca4047cc80d1dbaf8f4bf45c7..d5079ef7c4cf6c898da67d8ef128be8ac17b88cf 100644 (file)
--- a/src/backend/executor/execCurrent.c
+++ b/src/backend/executor/execCurrent.c
@@ -258,13 +258,15 @@ search_plan_tree(PlanState *node, Oid table_oid)
    switch (nodeTag(node))
    {
            /*
-            * scan nodes can all be treated alike
+            * Relation scan nodes can all be treated alike
             */
        case T_SeqScanState:
        case T_IndexScanState:
        case T_IndexOnlyScanState:
        case T_BitmapHeapScanState:
        case T_TidScanState:
+       case T_ForeignScanState:
+       case T_CustomScanState:
            {
                ScanState  *sstate = (ScanState *) node;