In postgres_fdw, don't try to ship MULTIEXPR updates to remote server. In a statement like "UPDATE remote_tab SET (x,y) = (SELECT ...)", we'd conclude that the statement could be directly executed remotely, because the sub-SELECT is in a resjunk tlist item that's not examined for shippability. Currently that ends up crashing if the sub-SELECT contains any remote Vars. Prevent the crash by deeming MULTIEXEC Params to be unshippable.
This is a bit of a brute-force solution, since if the sub-SELECT *doesn't* contain any remote Vars, the current execution technology would work; but that's not a terribly common use-case for this syntax, I think. In any case, we generally don't try to ship sub-SELECTs, so it won't surprise anybody that this doesn't end up as a remote direct update. I'd be inclined to see if that general limitation can be fixed before worrying about this case further. Per report from Lukáš Sobotka. Back-patch to 9.6. 9.5 had MULTIEXPR, but we didn't try to perform remote direct updates then, so the case didn't arise anyway. Discussion: https://postgr.es/m/cajif3k+ia_ekbb5zw2hdbae1wtiqa4lh4_juxrrmgwtrh0j...@mail.gmail.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7294f99a0b2043cf9b34a9a59ecb3dfbfae94f85 Modified Files -------------- contrib/postgres_fdw/deparse.c | 16 +++++++++++++ contrib/postgres_fdw/expected/postgres_fdw.out | 31 ++++++++++++++++++++++++++ contrib/postgres_fdw/sql/postgres_fdw.sql | 20 +++++++++++++++++ 3 files changed, 67 insertions(+)
