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
