Re: tripping an assert in 8.1.6 (more info) - Mailing list pgsql-hackers

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)
returnfalse;        /* 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)
returnfalse;        /* 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);    }