Re: 7.3 and HEAD broken for dropped columns of dropped types

I said:
> Fortunately, we are not up the proverbial creek with no paddle, because
> the only things we really need to know about the dropped column are its
> typlen and typalign --- which just happen to still be recorded in
> pg_attribute.attlen and attalign. (Let's hear it for denormalization.)
> It will take a little bit of code rearrangement to make that information
> available to ExecTypeFromTL(), but I see no alternative.

Actually, that idea doesn't work at all for the INSERT and UPDATE cases.
I was thinking that ExecTypeFromTL would see a Var that it could use to
look up the pg_attribute entry, but it won't --- what it will see in the
targetlist is a NULL constant. There is actually no way to determine
the required information from just looking at the targetlist entry; you
need to know the result-relation tupledesc more or less a-priori.

After chewing on that for awhile, I have decided that our current
approach to doing INSERT/UPDATE in tables with deleted columns is all
wrong. We should not try to generate a Plan tree in which there are
already nulls for deleted columns; instead, let the junkfilter code
insert the nulls. The junkfilter is only used at the top level of a
plan, and it can easily be handed the result-relation tupledesc that
it needs to match. This solution is free in the case of UPDATE,
since it will always need a junkfilter phase. It's not free for
INSERT, but the runtime cost seems fairly minimal. Given that INSERT
most commonly inserts only one row, runtime cost is probably not the
thing to worry about anyway --- setup costs are, and I think this'll be
more or less a wash, since the planner end of things is simplified.

Any comments?

regards, tom lane