diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-02-07 13:10:46 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-02-07 13:11:14 -0500 |
commit | e3101a0317a9171ced56b91e30d8929094d182eb (patch) | |
tree | 23c7c9bbddf58950fc0adf8c769f32adea570779 /src/backend/utils/adt/tsgistidx.c | |
parent | bbcafabb4462e8c8fc19bb191e16f3a78bb446aa (diff) | |
download | postgresql-e3101a0317a9171ced56b91e30d8929094d182eb.tar.gz postgresql-e3101a0317a9171ced56b91e30d8929094d182eb.zip |
Ensure that foreign scans with lateral refs are planned correctly.
As reported in bug #15613 from Srinivasan S A, file_fdw and postgres_fdw
neglected to mark plain baserel foreign paths as parameterized when the
relation has lateral_relids. Other FDWs have surely copied this mistake,
so rather than just patching those two modules, install a band-aid fix
in create_foreignscan_path to rectify the mistake centrally.
Although the band-aid is enough to fix the visible symptom, correct
the calls in file_fdw and postgres_fdw anyway, so that they are valid
examples for external FDWs.
Also, since the band-aid isn't enough to make this work for parameterized
foreign joins, throw an elog(ERROR) if such a case is passed to
create_foreignscan_path. This shouldn't pose much of a problem for
existing external FDWs, since it's likely they aren't trying to make such
paths anyway (though some of them may need a defense against joins with
lateral_relids, similar to the one this patch installs into postgres_fdw).
Add some assertions in relnode.c to catch future occurrences of the same
error --- in particular, as backstop against core-code mistakes like the
one fixed by commit bdd9a99aa.
Discussion: https://postgr.es/m/15613-092be1be9576c728@postgresql.org
Diffstat (limited to 'src/backend/utils/adt/tsgistidx.c')
0 files changed, 0 insertions, 0 deletions