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
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/a2387c32f2f8a1643c7d71b951587e6bcb2d4744

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(-)