pgsql: Don't convert Consts into Vars during setrefs.c processing.

Don't convert Consts into Vars during setrefs.c processing.

While converting expressions in an upper-level plan node so that they
reference Vars and expressions provided by the input plan node(s),
don't convert plain Const items, even if there happens to be a matching
Const in the input. It's silly to do so because a Var is more expensive to
execute than a Const. Moreover, converting can fool ExecCheckPlanOutput's
check that an insert or update query inserts nulls into dropped columns,
leading to "query provides a value for a dropped column" errors during
INSERT or UPDATE on a table with a dropped column. We could solve this
by making that check more complicated, but I don't see the point; this fix
should save a marginal number of cycles, and it also makes for less messy
EXPLAIN output, as shown by the ensuing regression test result changes.

Per report from Pavel Hanák. I have not incorporated a test case based
on that example, as there doesn't seem to be a simple way of checking
this in isolation without making a bunch of assumptions about other
planner and SQL-function behavior.

Back-patch to 9.6. This setrefs.c behavior exists much further back,
but there is not currently reason to think that it causes problems
before 9.6.

Discussion: <83shraampf(dot)fsf(at)is-it(dot)eu>

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/da8f3ebf30bef9c950595dc0d1f03bce2b1b8563

Modified Files
--------------
contrib/postgres_fdw/expected/postgres_fdw.out | 8 ++++----
src/backend/optimizer/plan/setrefs.c | 23 +++++++++++++++++++++++
src/test/regress/expected/inherit.out | 2 +-
3 files changed, 28 insertions(+), 5 deletions(-)