Tom Lane wrote:
I'm coming around to the idea that it'd be better to disable physical
tlists for custom scans.
I've been thinking about this all along, and it seems that this is a decent
decision. However, I've made a tiny bugfix patch which allows CustomScans
to notify the core code that they can handle physical targetlists.
Extension authors won't have to change anything provided that CustomPath is
allocated using palloc0().
However, I'm hesitant to make such a change in the back branches; if
there's anyone using custom scans who's negatively affected, they'd be
rightfully unhappy. Are you satisfied if we change this in HEAD?
It's kind of bittersweet. I'm really glad that you've changed your mind and
this is going to be fixed in HEAD, but this change is crucial for our
extension (if we use it with vanilla postgres).
Maybe you'll like my patch more.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 71678d08dc..4b0322530b 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -761,6 +761,9 @@ use_physical_tlist(PlannerInfo *root, Path *path, int flags)
if (rel->reloptkind != RELOPT_BASEREL)
return false;
+ if (IsA(path, CustomPath) && ((CustomPath *) path)->forbid_physical_tlist)
+ return false;
+
/*
* Can't do it if any system columns or whole-row Vars are requested.
* (This could possibly be fixed but would take some fragile assumptions
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index 48862d93ae..5a1f6cee47 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -1089,6 +1089,7 @@ typedef struct CustomPath
* nodes/extensible.h */
List *custom_paths; /* list of child Path nodes, if any */
List *custom_private;
+ bool forbid_physical_tlist;
const struct CustomPathMethods *methods;
} CustomPath;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
