BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values - Mailing list pgsql-bugs

The following bug has been logged on the website:

Bug reference:      17803
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 15.2
Operating system:   Ubuntu 22.04
Description:

The following queries:
CREATE TABLE t (a int, b int DEFAULT -1);
CREATE VIEW v AS SELECT * FROM t;
CREATE RULE vr AS ON INSERT TO v DO ALSO INSERT INTO t SELECT 1;
INSERT INTO v VALUES (0, DEFAULT), (1, DEFAULT);

lead to an assert for me:
Core was generated by `postgres: law regression [local] INSERT
                        '.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/1192422' in core file too small.
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140044862031680) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140044862031680) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140044862031680) at
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140044862031680, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3  0x00007f5ebb90e476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4  0x00007f5ebb8f47f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x0000562faf172cf6 in ExceptionalCondition (conditionName=0x562faf346725
"rte->rtekind == RTE_VALUES", 
    errorType=0x562faf3462b3 "FailedAssertion", fileName=0x562faf34634c
"rewriteHandler.c", lineNumber=1600)
    at assert.c:69
#6  0x0000562faef2c936 in rewriteValuesRTEToNulls (parsetree=0x562fb1232028,
rte=0x562fb13002f0)
    at rewriteHandler.c:1600
#7  0x0000562faef30be1 in RewriteQuery (parsetree=0x562fb1232140,
rewrite_events=0x0, orig_rt_length=0)
    at rewriteHandler.c:3878
#8  0x0000562faef316da in QueryRewrite (parsetree=0x562fb1232140) at
rewriteHandler.c:4168
#9  0x0000562faef9dc61 in pg_rewrite_query (query=0x562fb1232140) at
postgres.c:792
#10 0x0000562faef9da2e in pg_analyze_and_rewrite_fixedparams
(parsetree=0x562fb1231f98, 
    query_string=0x562fb12311b0 "INSERT INTO v VALUES (0, DEFAULT), (1,
DEFAULT);", paramTypes=0x0, numParams=0, 
    queryEnv=0x0) at postgres.c:666
#11 0x0000562faef9e269 in exec_simple_query (
    query_string=0x562fb12311b0 "INSERT INTO v VALUES (0, DEFAULT), (1,
DEFAULT);") at postgres.c:1166
#12 0x0000562faefa3339 in PostgresMain (dbname=0x562fb125d658 "regression",
username=0x562fb125d638 "law")
    at postgres.c:4593
#13 0x0000562faeec8afb in BackendRun (port=0x562fb1254d70) at
postmaster.c:4511
#14 0x0000562faeec8382 in BackendStartup (port=0x562fb1254d70) at
postmaster.c:4239
#15 0x0000562faeec430f in ServerLoop () at postmaster.c:1806
#16 0x0000562faeec3a6c in PostmasterMain (argc=3, argv=0x562fb122c670) at
postmaster.c:1478
#17 0x0000562faedb79ad in main (argc=3, argv=0x562fb122c670) at main.c:202

Without asserts enabled I get:
ERROR:  unrecognized node type: 148
STATEMENT:  INSERT INTO v VALUES (0, DEFAULT), (1, DEFAULT);

It looks like this is originated from the commit 41531e42d
that was prepared only for "ALSO INSERT ... VALUES ..." (before it
INSERT SELECT worked just as incorrectly as INSERT VALUES),
and the following commits (ed4653db8,  b8f2687fd, 2605643a),
which massaged that code didn't fix things for this scenario yet.