A bug with ExecCheckPermissions

Greetings, everyone!

While working on an extension my colleague and I have found an
interesting case;

When you try to execute next SQL statements on master branch of
PostgreSQL:

CREATE TABLE parted_fk_naming (
id bigint NOT NULL default 1,
id_abc bigint,
CONSTRAINT dummy_constr FOREIGN KEY (id_abc)
REFERENCES parted_fk_naming (id),
PRIMARY KEY (id)
)
PARTITION BY LIST (id);

CREATE TABLE parted_fk_naming_1 (
id bigint NOT NULL default 1,
id_abc bigint,
PRIMARY KEY (id),
CONSTRAINT dummy_constr CHECK (true)
);

ALTER TABLE parted_fk_naming ATTACH PARTITION parted_fk_naming_1 FOR
VALUES IN ('1');

seemingly nothing suspicious happens.
But if you debug function ExecCheckPermissions and look into what is
passed to function (contents of rangeTable and rteperminfos to be
exact),
you'll see some strange behaviour:

(
{RANGETBLENTRY
:alias <>
:eref <>
:rtekind 0
:relid 16395
:relkind r
:rellockmode 1
:tablesample <>
:perminfoindex 0
:lateral false
:inh false
:inFromCl false
:securityQuals <>
}
{RANGETBLENTRY
:alias <>
:eref <>
:rtekind 0
:relid 16384
:relkind p
:rellockmode 1
:tablesample <>
:perminfoindex 0
:lateral false
:inh false
:inFromCl false
:securityQuals <>
}
)

(
{RTEPERMISSIONINFO
:relid 16395
:inh false
:requiredPerms 2
:checkAsUser 0
:selectedCols (b 9)
:insertedCols (b)
:updatedCols (b)
}
{RTEPERMISSIONINFO
:relid 16384
:inh false
:requiredPerms 2
:checkAsUser 0
:selectedCols (b 8)
:insertedCols (b)
:updatedCols (b)
}
)

Both of RangeTableEntries have a perminfoindex of 0 and simultaneously
have a RTEPERMISSIONINFO entry for them!

Right now this behaviour isn't affecting anything, but in future should
someone want to use ExecutorCheckPerms_hook from
/src/backend/executor/execMain.c, its input parameters
won't correspond to each other since members of rangeTable will have
incorrect perminfoindex.

To fix this, we're setting fk's index to 1 and pk's index to 2 in
/src/backend/utils/adt/ri_triggers.c so that list being passed to
ExecCheckPermissions and its hook
has indexes for corresponding rteperminfos entries. 1 and 2 are chosen
because perminfoindex is 1-based and fk is passed to list_make2 first;

We are eager to hear some thoughts from the community!

Regards,

Oleg Tselebrovskii