aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/sql/postgres_fdw.sql
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-06-04 20:07:08 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-06-04 20:07:08 -0400
commitf61db909dfb94f3411f8719916601a11a905b95e (patch)
tree2e754af5cb4a64ac1377c288ff16638dc97eda84 /contrib/postgres_fdw/sql/postgres_fdw.sql
parent8f3c06c5d56fc0fa414bcf548860ac50a8fe5982 (diff)
downloadpostgresql-f61db909dfb94f3411f8719916601a11a905b95e.tar.gz
postgresql-f61db909dfb94f3411f8719916601a11a905b95e.zip
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
Diffstat (limited to 'contrib/postgres_fdw/sql/postgres_fdw.sql')
-rw-r--r--contrib/postgres_fdw/sql/postgres_fdw.sql8
1 files changed, 8 insertions, 0 deletions
diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql
index 17dba77d7ec..79295e996dd 100644
--- a/contrib/postgres_fdw/sql/postgres_fdw.sql
+++ b/contrib/postgres_fdw/sql/postgres_fdw.sql
@@ -1255,6 +1255,14 @@ UPDATE ft2 AS target SET (c2) = (
WHERE target.c1 = src.c1
) WHERE c1 > 1100;
+-- Test UPDATE involving a join that can be pushed down,
+-- but a SET clause that can't be
+EXPLAIN (VERBOSE, COSTS OFF)
+UPDATE ft2 d SET c2 = CASE WHEN random() >= 0 THEN d.c2 ELSE 0 END
+ FROM ft2 AS t WHERE d.c1 = t.c1 AND d.c1 > 1100;
+UPDATE ft2 d SET c2 = CASE WHEN random() >= 0 THEN d.c2 ELSE 0 END
+ FROM ft2 AS t WHERE d.c1 = t.c1 AND d.c1 > 1100;
+
-- Test UPDATE/DELETE with WHERE or JOIN/ON conditions containing
-- user-defined operators/functions
ALTER SERVER loopback OPTIONS (DROP extensions);