I was just shown the following example: CREATE TABLE profile (haushaltseinkommen_pm numeric(22,2)); CREATE VIEW profile_view AS SELECT *, haushaltseinkommen_pm*12 AS haushaltseinkommen_pa FROM profile; 7.0.* pg_dump produces the following for the view: CREATE TABLE "profile_view" ( "haushaltseinkommen_pm" numeric(22,2), "haushaltseinkommen_pa" numeric ); CREATE RULE "_RETprofile_view" AS ON SELECT TO profile_view DO INSTEAD SELECT profile.haushaltseinkommen_pm, (profile.haushaltseinkommen_pm * '12'::"numeric") AS haushaltseinkommen_pa FROM profile; AFAICS this is perfectly legitimate, but both 7.0.* and current backends will reject the CREATE RULE with ERROR: select rule's target entry 2 has different size from attribute haushaltseinkommen_pa The problem here is that DefineQueryRewrite checks if (attr->atttypmod != resdom->restypmod) elog(ERROR, "select rule's target entry %d has different size from attribute %s", i, attname); where attr will have the default precision/scale for NUMERIC, as set up by the CREATE TABLE, but resdom will have -1 because that's what you're going to get from a numeric expression. (In the CREATE VIEW case, they both have -1, evidently because CREATE VIEW doesn't force a default NUMERIC precision to be inserted in the table definition. Not sure if that's OK or not.) I think we'd better fix this, else we will have problems reading 7.0 dump files. I can see two possible answers: 1. Remove this check entirely. 2. Allow the typmods to be different if one of them is -1. I'm not entirely sure which way to jump. The former seems simpler but might perhaps allow creation of bogus views --- any opinions? regards, tom lane