Re: table unreadable after altering related table embedded via a view

Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> writes:
> Le lundi 22 novembre 2021, 03:44:37 CET Miles Delahunty a écrit :
>> ERROR: record type has not been registered

> I started to take a look at this, and while I haven't gotten to the bottom of
> it yet, here are my observations.

Thanks for poking at it! I dug a bit further and found that the
proximate cause of the problem is ExecTypeSetColNames, which is
deciding that the column names of a wholerow Var have changed
and then changing the output tuple type to RECORD.

Now, in the example as given, the *live* column names haven't
changed. So one problem is that ExecTypeSetColNames isn't
expecting that the tupdesc's attisdropped columns might not
exactly line up with the colnames list it's given. We could
hack that up to work, but if you change the example so that
the names don't match, say by skipping the "rename big_data
to data" step, the failure comes right back.

The reason the passed-in colnames list doesn't match is that
it's from the view's stored RTE for foo, which still has the
original colnames list of just ("data"), with no allowance for
any adjustments made after the view was created.

This code all comes from commit bf7ca1587. I think changing the
column names to match the RTE is essential if we want to have the
desired semantics for the examples in that commit. And once we
do that, the tuples are indeed not of the original rowtype, so
switching to RECORD seems unavoidable. The problem is that
we're allowing the now-RECORD tuples to be stored back into a
table. I think we've got to throw an error instead. But we
don't, because the code that's responsible for checking that
is looking at the Var in the query's tlist and seeing that it
claims to emit values of the appropriate rowtype.

So it seems to me that this is a basic design error in bf7ca1587
(and hence my fault :-(). We should not be trying to hack up
the values' rowtype in the executor; that has to happen earlier,
probably in the planner, and then we must fix the whole-row
Var to tell the truth about which rowtype it will emit.

I'll work on a fix, but it's probably not a trivial patch.

regards, tom lane