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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers