pgsql: Fix incorrect logic for caching ResultRelInfos for triggers

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo. There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo. This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple. We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <dgrowleyml(at)gmail(dot)com>
Author: Amit Langote <amitlangote09(at)gmail(dot)com>
Reported-by: Dmitry Fomin <fomin(dot)list(at)gmail(dot)com>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/39dcfda2d23ac39f14ecf4b83e01eae85d07d9e5

Modified Files
--------------
src/backend/executor/execMain.c | 24 ++++++++++-----
src/test/regress/expected/foreign_key.out | 51 +++++++++++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql | 48 +++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 7 deletions(-)