tripping an assert in 8.1.6

Hello all. It seems I'm tripping an assert in 8.1.6- the assert on line
219 of src/backend/executor/execScan.c (found by running gdb on a core
dump). This is on x86 and Redhat Linux (forget which version). Note
that if I recompile 8.1.6 with asserts turned off the query completes
just fine. I'm trying to put together an example which reproduces the
problem without requiring half our company's data- that should follow soon.

The gdb backtrace is:

> #0 0xffffe410 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0xb7d2dee9 in raise () from /lib/libc.so.6
> #2 0xb7d2f4f1 in abort () from /lib/libc.so.6
> #3 0x0824f931 in ExceptionalCondition (conditionName=Variable
> "conditionName" is not available.
> ) at assert.c:51
> #4 0x081537ac in ExecAssignScanProjectionInfo (node=0x8426bec)
> at execScan.c:219
> #5 0x08161339 in ExecInitSubqueryScan (node=0x8412de4, estate=0x8426ad4)
> at nodeSubqueryscan.c:212
> #6 0x0814e0e4 in ExecInitNode (node=0x8412de4, estate=0x8426ad4)
> at execProcnode.c:179
> #7 0x0814c554 in ExecutorStart (queryDesc=0x842554c, explainOnly=1
> '\001')
> at execMain.c:618
> #8 0x081193f5 in ExplainOnePlan (queryDesc=0x842554c, stmt=0x839afe4,
> tstate=0x83cbdac) at explain.c:243
> #9 0x081198ac in ExplainOneQuery (query=0x83b88e4, stmt=0x839afe4,
> tstate=0x83cbdac) at explain.c:214
> #10 0x08119a92 in ExplainQuery (stmt=0x839afe4, dest=0x83b8a54)
> at explain.c:121
> #11 0x081da391 in PortalRunUtility (portal=0x83b67b4, query=0x839b07c,
> dest=0x83b8a54, completionTag=0x0) at pquery.c:987
> #12 0x081db6dc in PortalRun (portal=0x83b67b4, count=2147483647,
> dest=0x839b030, altdest=0x839b030, completionTag=0xbf9efee8 "")
> at pquery.c:637
> #13 0x081d713c in exec_simple_query (
> query_string=0x839a26c "explain SELECT action, bloomberg_code,
> composite_bloomberg_code, reuters_code, cusip_code, sedol_code,
> isin_code FROM vw_ca_generic_actions WHERE (action_date >=
> '20070122'::date) AND (action_date <= "...)
> at postgres.c:1004
> #14 0x081d8bd3 in PostgresMain (argc=4, argv=0x83593f0,
> username=0x83593b8 "postgres") at postgres.c:3232
> #15 0x081aca37 in ServerLoop () at postmaster.c:2865
> #16 0x081ad936 in PostmasterMain (argc=3, argv=0x8358560) at
> postmaster.c:941
> #17 0x0816c1c9 in main (argc=3, argv=Cannot access memory at address
> 0x1515
> ) at main.c:265
>

This is mainly a "heads up- bug incomming" message. Thanks.

Brian