Re: BUG #17811: Replacing an underlying view breaks OLD/NEW tuple when accessing it via upper-level view

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> I've discovered an issue with replacing a view when there is another
> updatable view defined on top of it and the new underlying view has
> more columns than the previous one.

I've looked into this a bit more, and both of these symptoms reduce
to the same thing: after we've plugged the modified view's query
into the upper query, we have an RTE_SUBQUERY RTE whose eref->colnames
list is shorter than the number of columns actually available from the
subquery. This breaks assorted code that is expecting that it can
use list_length(eref->colnames) as a quick guide to the number of
output columns.

We have seen this before (bug #14876, commit d5b760ecb) and at the
time our response was to patch up the code making such an assumption.
But you've just demonstrated at least two other places with the same
issue, so now I'm feeling that we'd be best advised to fix it
centrally in the rewriter code that plugs in the view definition.
The attached fix causes a change in the regression test output for
bug #14876's test case, but AFAICS the change is a strict improvement:
we get something sane, not a NULL, for the added column.

I'm not sure whether to change the code added to expandRTE in
d5b760ecb or leave it be. We could make it into elog(ERROR) now,
perhaps.

regards, tom lane