change_varattnos_of_a_node versus whole-row Vars

change_varattnos_of_a_node(), which is used to adjust expressions
referencing a parent relation or LIKE source relation to refer to the
child relation, ignores whole-row Vars (those with attnum zero).
Thus, after processing the expression, the whole-row Var still claims
to have the rowtype (vartype) of the parent rel. This is utterly wrong
in the LIKE case, as pointed out in
http://archives.postgresql.org/pgsql-general/2012-06/msg00674.php
and AFAICS it is wrong in the inheritance case too, since there's
no guarantee that the parent and child rowtypes are binary-equivalent.

My inclination, especially in the back branches, is to just throw error
if we find a whole-row Var. ISTM the entire point of CREATE TABLE LIKE
is that the two tables' rowtypes might diverge after the child is
created, so it makes no sense to do anything that would presuppose that
an expression involving the parent's rowtype will remain sensible for
the child. The only caller not associated with CREATE TABLE LIKE is
MergeAttributes, which is trying to adjust CHECK constraints for a
parent rel to apply to a new inheritance child. In that case it would
be sensible to expect a "parent.*" reference to be valid for the child
(though a ConvertRowtypeExpr would still need to be thrown in to make
this work). However, it's hard to implement because the Var would need
to be modified to contain the rowtype OID for the child relation, which
has not been assigned at this point. In principle we could rearrange
CREATE TABLE processing enough so that inherited CHECK constraints
aren't adjusted till after we know the rowtype OID, but I'm not
personally volunteering to do that.

There are a bunch of other things I don't like about
change_varattnos_of_a_node, starting with the name, but those gripes are
in the nature of cosmetics or inadequate error checking and wouldn't
have any user-visible impact if changed.

Any thoughts on the topic?

regards, tom lane