(2) when any of xmins, xmaxs, cmins, and cmaxs are requested, postgres_fdw gives up pushing down foreign joins. (We might be able to set appropriate values for them locally the same way as for tableoids, but I'm not sure it's worth complicating the code.) I think that would be probably OK, because users wouldn't retrieve any such columns in practice.
In that patch you have set pushdown_safe to false for the base relation fetching system columns. But pushdown_safe = false means that that relation is not safe to push down. A base foreign relation is always safe to push down, so should have pushdown_safe = true always. Instead, I suggest having a separate boolean has_unshippable_syscols (or something with similar name) in PgFdwRelationInfo, which is set to true in such case. In foreign_join_ok, we return false (thus not pushing down the join), if any of the joining relation has that attribute set. By default this member is false.
Maybe I'm missing something, but why do you consider that base foreign tables need always be safe to push down? IIUC, the pushdown_safe flag is used only for foreign_join_ok, so I think that a base foreign table needs not necessarily be safe to push down.
A base foreign table "always" fetches data from the foreign server, so it "has to be" always safe to push down. pushdown_safe flag is designated to tell whether the relation corresponding to PgFdwRelationInfo where this flag is set is safe to push down.Right now it's only used for joins but in future it would be used for any push down of higher operations. It seems very much possible after the upper pathification changes. We can not have a query sent to the foreign server for a relation, when pushdown_safe is false for that. Your patch does that for foreign base relation which try to fetch system columns.
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company