So, I'd like to propose: (1) when tableoids are requested from the remote server, postgres_fdw sets valid values for them locally, instead (core should support that?)
Sure.
and (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.
Now that seems like the wrong reaction. I mean, aren't these just going to be 0 or something? Refusing to push the join down seems strange.
OK, I'll modify the patch so that the join is pushed down even if any of xmins, xmaxs, cmins, and cmaxs are requested. Do you think which one should set values for these as well as tableoids, postgres_fdw or core?
Earlier in this mail chain, I suggested that the core should take care of storing the values for these columns. But instead, I think, core should provide functions which can be used by FDWs, if they want, to return values for those columns. Something like Datum get_syscol_value(RelOptInfo/Relation, attno). The function will return Datum 0 for most of the columns and table's OID for tableoid. My 0.02. --
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company