I wrote:
> After further thought I've developed a modified version of Brian's case
> that crashes 8.2 and HEAD but not 8.1 --- it turns the situation around
> by having the view fall back to typmod -1. So what I'm now thinking
> is that the real problem is that an Append path generates its Vars by
> copying the first input, and in these sorts of situations that might not
> produce the correct typmod. Back to the drawing board ...
Nope, that's not right either. What it seems to boil down to is what I
said the first time: removal of trivial subqueryscans can leave us with
a plan that uses an above-a-union Var to describe a value from one of
the union inputs. Some other 8.2 changes moved the subqueryscans
around, which is why the cases that manifest are a bit different, but
in the end it's the same issue.
I've concluded that this isn't really wrong; it's certainly not worth
disabling the trivial-subqueryscan optimization for, and I think getting
the planner to avoid the problem without that would be tricky.
Accordingly, I've applied the attached patch that just relaxes the
Assert.
regards, tom lane
Index: execScan.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/executor/execScan.c,v
retrieving revision 1.39
diff -c -r1.39 execScan.c
*** execScan.c 5 Jan 2007 22:19:27 -0000 1.39
--- execScan.c 24 Jan 2007 01:03:03 -0000
***************
*** 215,222 ****
return false; /* out of order */
if (att_tup->attisdropped)
return false; /* table contains dropped
columns */
Assert(var->vartype == att_tup->atttypid);
! Assert(var->vartypmod == att_tup->atttypmod);
tlist_item = lnext(tlist_item);
}
--- 215,232 ----
return false; /* out of order */
if (att_tup->attisdropped)
return false; /* table contains dropped
columns */
+ /*
+ * Note: usually the Var's type should match the tupdesc
exactly,
+ * but in situations involving unions of columns that have
different
+ * typmods, the Var may have come from above the union and
hence have
+ * typmod -1. This is a legitimate situation since the Var
still
+ * describes the column, just not as exactly as the tupdesc
does.
+ * We could change the planner to prevent it, but it'd then
insert
+ * projection steps just to convert from specific typmod to
typmod -1,
+ * which is pretty silly.
+ */
Assert(var->vartype == att_tup->atttypid);
! Assert(var->vartypmod == att_tup->atttypmod || var->vartypmod
== -1);
tlist_item = lnext(tlist_item);
}
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
