BUG #15733: An insert destined at partition created after a column has been dropped from the parent table fails

The following bug has been logged on the website:

Bug reference: 15733
Logged by: Petr Fedorov
Email address: petr(dot)fedorov(at)phystech(dot)edu
PostgreSQL version: 11.2
Operating system: Centos7
Description:

Steps to reproduce:

1. Create a table to be partitioned

create table public.partitioned ( id integer not null, level1 integer not
null, level2 integer not null, level3 integer not null, data1 integer not
null, data2 integer not null) partition by list (level1) ;

2. Create partitions for some values:

create table public.partitioned_1 partition of public.partitioned for
values in (1) partition by list(level2);
create table public.partitioned_1_1 partition of public.partitioned_1 for
values in (1) partition by list(level3);
create table public.partitioned_1_1_1 partition of public.partitioned_1_1
for values in (1);

3. Drop some column from the partitioned table:

alter table partitioned drop column data1;

4. Create partitions for another value:

create table public.partitioned_2 partition of public.partitioned for
values in (2) partition by list(level2);
create table public.partitioned_2_1 partition of public.partitioned_2 for
values in (1) partition by list (level3);
create table public.partitioned_2_1_1 partition of public.partitioned_2_1
for values in (1);

5. Insert the row which would land at partitioned_1_1_1 - works:

insert into partitioned values(1,1,1,1,1);

6. FAIL: Insert the row which would land at partitioned_2_1_1:

insert into partitioned values(2,2,1, 1,1);

ERROR: cannot extract attribute from empty tuple slot SQL state: XX000

7. Still you can insert using partition_2 - works:

insert into partitioned_2 values(2,2,1, 1,1);