Re: BUG #3882: unexpected PARAM_SUBLINK ID

"Jan Mate" <mate@yeea.eu> writes:
> I get the following error:
> ERROR:  unexpected PARAM_SUBLINK ID: 3

This is an interesting test case.  The problem is coming from the part
of the rule that has

    (new.number, new.limited, new."level") IN (SELECT ...)

The parser transforms this to a SubLink with a "testexpr" that
looks like

    V1 = P1 AND V2 = P2 AND V3 = P3

where the V's are Vars representing the new.* fields and the P's
are PARAM_SUBLINK Params representing the output columns of the
sub-SELECT.

The planner's subselect.c assumes that the testexpr will still
look like that, at least to the extent of referencing the same
Params in the same order, by the time it sees the SubLink.
This assumption was always a bit shaky, as noted in the code,
but I had not seen a case that breaks it.  What happens is that
for an ON INSERT rule with INSERT / VALUES, the rewriter substitutes
the VALUES-list items for the new.* Vars, which in this case
yields

    1 = P1 AND null = P2 AND 1 = P3

and then const-simplification reasons that timestamp equality is a
strict operator and therefore cannot succeed on constant-null input,
so the result of eval_const_expressions is just

    1 = P1 AND 1 = P3

causing subselect.c to choke because there's no Param corresponding
to the second subselect output column.

I thought for a bit about a band-aid fix involving doing sublink
expansion before const-simplification, but really the right answer
is to get rid of the shaky assumption.  Instead of relying on
one-for-one matching of Param uses, subselect.c should scan the
subselect's output targetlist for itself to determine the number
and types of the output columns.  This involves duplicating some
code from the parser's transformSubLink, but only about a dozen
lines worth.  (It was trying to avoid duplicating that logic that
led me down the garden path to this error :-()  The substitution
for the PARAM_SUBLINK Params still needs to happen, but that
should be driven off list_nth() selection from the result of this
scan, instead of assuming that the Params appear in any particular
ordering.

Will fix.

            regards, tom lane