Fix postgres_fdw failure with whole-row Vars of type RECORD.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 5 Jun 2021 00:07:08 +0000 (20:07 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 5 Jun 2021 00:07:08 +0000 (20:07 -0400)
commitf61db909dfb94f3411f8719916601a11a905b95e
tree2e754af5cb4a64ac1377c288ff16638dc97eda84
parent8f3c06c5d56fc0fa414bcf548860ac50a8fe5982
Fix postgres_fdw failure with whole-row Vars of type RECORD.

Commit 86dc90056 expects that FDWs can cope with whole-row Vars for
their tables, even if the Vars are marked with vartype RECORDOID.
Previously, whole-row Vars generated by the planner had vartype equal
to the relevant table's rowtype OID.  (The point behind this change is
to enable sharing of resjunk columns across inheritance child tables.)

It turns out that postgres_fdw fails to cope with this, though through
bad fortune none of its test cases exposed that.  Things mostly work,
but when we try to read back a value of such a Var, the expected
rowtype is not available to record_in().  Fortunately, it's not
difficult to hack up the tupdesc that controls this process to
substitute the foreign table's rowtype for RECORDOID.  Thus we can
solve the runtime problem while still sharing the resjunk column
with other tables.

Per report from Alexander Pyhalov.

Discussion: https://postgr.es/m/7817fb9ebd6661cdf9b67dec6e129a78@postgrespro.ru
contrib/postgres_fdw/expected/postgres_fdw.out
contrib/postgres_fdw/postgres_fdw.c
contrib/postgres_fdw/sql/postgres_fdw.sql