postgresql/contrib
Tom Lane 8cad5adb9c Avoid postgres_fdw crash for a targetlist entry that's just a Param.
foreign_grouping_ok() is willing to put fairly arbitrary expressions into
the targetlist of a remote SELECT that's doing grouping or aggregation on
the remote side, including expressions that have no foreign component to
them at all.  This is possibly a bit dubious from an efficiency standpoint;
but it rises to the level of a crash-causing bug if the expression is just
a Param or non-foreign Var.  In that case, the expression will necessarily
also appear in the fdw_exprs list of values we need to send to the remote
server, and then setrefs.c's set_foreignscan_references will mistakenly
replace the fdw_exprs entry with a Var referencing the targetlist result.

The root cause of this problem is bad design in commit e7cb7ee14: it put
logic into set_foreignscan_references that IMV is postgres_fdw-specific,
and yet this bug shows that it isn't postgres_fdw-specific enough.  The
transformation being done on fdw_exprs assumes that fdw_exprs is to be
evaluated with the fdw_scan_tlist as input, which is not how postgres_fdw
uses it; yet it could be the right thing for some other FDW.  (In the
bigger picture, setrefs.c has no business assuming this for the other
expression fields of a ForeignScan either.)

The right fix therefore would be to expand the FDW API so that the
FDW could inform setrefs.c how it intends to evaluate these various
expressions.  We can't change that in the back branches though, and we
also can't just summarily change setrefs.c's behavior there, or we're
likely to break external FDWs.

As a stopgap, therefore, hack up postgres_fdw so that it won't attempt
to send targetlist entries that look exactly like the fdw_exprs entries
they'd produce.  In most cases this actually produces a superior plan,
IMO, with less data needing to be transmitted and returned; so we probably
ought to think harder about whether we should ship tlist expressions at
all when they don't contain any foreign Vars or Aggs.  But that's an
optimization not a bug fix so I left it for later.  One case where this
produces an inferior plan is where the expression in question is actually
a GROUP BY expression: then the restriction prevents us from using remote
grouping.  It might be possible to work around that (since that would
reduce to group-by-a-constant on the remote side); but it seems like a
pretty unlikely corner case, so I'm not sure it's worth expending effort
solely to improve that.  In any case the right long-term answer is to fix
the API as sketched above, and then revert this hack.

Per bug #15781 from Sean Johnston.  Back-patch to v10 where the problem
was introduced.

Discussion: https://postgr.es/m/15781-2601b1002bad087c@postgresql.org
2019-04-27 13:15:54 -04:00
..
adminpack Update copyright for 2019 2019-01-02 12:44:25 -05:00
amcheck Sanitize line pointers within contrib/amcheck. 2019-04-25 12:50:37 -07:00
auth_delay Update copyright for 2019 2019-01-02 12:44:25 -05:00
auto_explain Add SETTINGS option to EXPLAIN, to print modified settings. 2019-04-04 00:04:31 +02:00
bloom Report progress of CREATE INDEX operations 2019-04-02 15:18:08 -03:00
btree_gin Provide separate header file for built-in float types 2018-07-29 03:30:48 +02:00
btree_gist Change floating-point output format for improved performance. 2019-02-13 15:20:33 +00:00
citext Move hash_any prototype from access/hash.h to utils/hashutils.h 2019-03-11 13:17:50 -03:00
cube Change floating-point output format for improved performance. 2019-02-13 15:20:33 +00:00
dblink Initialize structure at declaration 2019-03-25 09:36:58 +01:00
dict_int Update copyright for 2019 2019-01-02 12:44:25 -05:00
dict_xsyn Update copyright for 2019 2019-01-02 12:44:25 -05:00
earthdistance Fix earthdistance test suite function name typo. 2018-07-29 12:02:07 -07:00
file_fdw file_fdw: Fix for generated columns 2019-04-04 09:24:48 +02:00
fuzzystrmatch Update copyright for 2019 2019-01-02 12:44:25 -05:00
hstore Move hash_any prototype from access/hash.h to utils/hashutils.h 2019-03-11 13:17:50 -03:00
hstore_plperl Still further rethinking of build changes for macOS Mojave. 2018-10-18 14:55:23 -04:00
hstore_plpython Avoid Python memory leaks in hstore_plpython and jsonb_plpython. 2019-04-06 17:54:29 -04:00
intagg Schema-qualify some references to regprocedure. 2016-06-10 10:41:58 -04:00
intarray Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT. 2019-02-15 23:22:33 -05:00
isn Update copyright for 2019 2019-01-02 12:44:25 -05:00
jsonb_plperl Still further rethinking of build changes for macOS Mojave. 2018-10-18 14:55:23 -04:00
jsonb_plpython Avoid Python memory leaks in hstore_plpython and jsonb_plpython. 2019-04-06 17:54:29 -04:00
lo lo: Add test suite 2017-09-14 22:22:59 -04:00
ltree Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT. 2019-02-15 23:22:33 -05:00
ltree_plpython Fix out-of-tree build for transform modules. 2018-09-16 18:46:45 +01:00
oid2name Replace @postgresql.org with @lists.postgresql.org for mailinglists 2019-01-19 19:06:35 +01:00
pageinspect Only allow heap in a number of contrib modules. 2019-04-01 14:57:21 -07:00
passwordcheck Update copyright for 2019 2019-01-02 12:44:25 -05:00
pg_buffercache Remove WITH OIDS support, change oid catalog column visibility. 2018-11-20 16:00:17 -08:00
pg_freespacemap Replace heapam.h includes with {table, relation}.h where applicable. 2019-01-21 10:51:37 -08:00
pg_prewarm Don't auto-restart per-database autoprewarm workers. 2019-03-18 15:22:42 -04:00
pg_standby Replace @postgresql.org with @lists.postgresql.org for mailinglists 2019-01-19 19:06:35 +01:00
pg_stat_statements Move hash_any prototype from access/hash.h to utils/hashutils.h 2019-03-11 13:17:50 -03:00
pg_trgm Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT. 2019-02-15 23:22:33 -05:00
pg_visibility Move remaining code from tqual.[ch] to heapam.h / heapam_visibility.c. 2019-01-21 17:07:10 -08:00
pgcrypto Suppress another case of MSVC warning 4146. 2019-02-16 15:28:27 -08:00
pgrowlocks Only allow heap in a number of contrib modules. 2019-04-01 14:57:21 -07:00
pgstattuple Only allow heap in a number of contrib modules. 2019-04-01 14:57:21 -07:00
postgres_fdw Avoid postgres_fdw crash for a targetlist entry that's just a Param. 2019-04-27 13:15:54 -04:00
seg Change floating-point output format for improved performance. 2019-02-13 15:20:33 +00:00
sepgsql Move hash_any prototype from access/hash.h to utils/hashutils.h 2019-03-11 13:17:50 -03:00
spi Fix more strcmp() calls using boolean-like comparisons for result checks 2019-04-12 10:16:49 +09:00
sslinfo Phase 3 of pgindent updates. 2017-06-21 15:35:54 -04:00
start-scripts Remove contrib/start-scripts/osx/. 2017-11-17 12:53:20 -05:00
tablefunc Switch some palloc/memset calls to palloc0 2019-03-27 12:02:50 +09:00
tcn Update copyright for 2019 2019-01-02 12:44:25 -05:00
test_decoding Add facility to copy replication slots 2019-04-05 18:05:18 -03:00
tsm_system_rows tableam: sample scan. 2019-03-31 18:37:57 -07:00
tsm_system_time tableam: sample scan. 2019-03-31 18:37:57 -07:00
unaccent Add combining characters to unaccent.rules. 2019-02-01 15:23:01 +01:00
uuid-ossp Update copyright for 2019 2019-01-02 12:44:25 -05:00
vacuumlo Avoid double-free in vacuumlo error path. 2019-03-24 15:13:20 -04:00
xml2 Phase 3 of pgindent updates. 2017-06-21 15:35:54 -04:00
contrib-global.mk Respect TEMP_CONFIG when pg_regress_check and friends are called 2016-02-27 12:28:21 -05:00
Makefile Transforms for jsonb to PL/Perl 2018-04-03 09:47:18 -04:00
README Rename 'gmake' to 'make' in docs and recommended commands 2014-02-12 17:29:19 -05:00

The PostgreSQL contrib tree
---------------------------

This subtree contains porting tools, analysis utilities, and plug-in
features that are not part of the core PostgreSQL system, mainly
because they address a limited audience or are too experimental to be
part of the main source tree.  This does not preclude their
usefulness.

User documentation for each module appears in the main SGML
documentation.

When building from the source distribution, these modules are not
built automatically, unless you build the "world" target.  You can
also build and install them all by running "make all" and "make
install" in this directory; or to build and install just one selected
module, do the same in that module's subdirectory.

Some directories supply new user-defined functions, operators, or
types.  To make use of one of these modules, after you have installed
the code you need to register the new SQL objects in the database
system by executing a CREATE EXTENSION command.  In a fresh database,
you can simply do

    CREATE EXTENSION module_name;

See the PostgreSQL documentation for more information about this
procedure.