I don't think it's a good idea to make such checks at runtime - and either way it's somethign that should be reported back using an ereport(), not an elog.
Also, it seems somewhat wrong to determine this at execution time. Shouldn't this rather be done when creating the foreign scan node? And be a part of the scan state?
I agree, that was my original plan, but I wasn't familiar enough with the FDW architecture to know where the table struct and the scan struct were both exposed in the same function.
What I submitted incorporated some of Kyotaro's feedback (and working patch) to my original incomplete patch.
Have you thought about how this option should cooperate with join pushdown once implemented?
I hadn't until now, but I think the only sensible thing would be to disregard table-specific settings once a second foreign table is detected, and instead consider only the server-level setting.
I suppose one could argue that if ALL the tables in the join had the same table-level setting, we should go with that, but I think that would be complicated, expensive, and generally a good argument for changing the server setting instead.
