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

                        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 
+                * but in situations involving unions of columns that have 
+                * typmods, the Var may have come from above the union and 
hence have
+                * typmod -1.  This is a legitimate situation since the Var 
+                * describes the column, just not as exactly as the tupdesc 
+                * We could change the planner to prevent it, but it'd then 
+                * 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?


Reply via email to