planner crash/assert hit in 8.4B1

While playing with 8.4b1 against one of our production databases I
quickly managed to run into the following assert:

Program received signal SIGSEGV, Segmentation fault.
0x082d27ef in estimate_num_groups (root=0x8566398, groupExprs=0x85b9ed8,
input_rows=1159344) at selfuncs.c:3071
3071 Assert(rel->reloptkind == RELOPT_BASEREL);
#0 0x082d27ef in estimate_num_groups (root=0x8566398,
groupExprs=0x85b9ed8, input_rows=1159344) at selfuncs.c:3071
#1 0x08221b1c in create_unique_path (root=0x8566398, rel=0x85b746c,
subpath=0x85b88bc, sjinfo=0x85b15cc) at pathnode.c:960
#2 0x08205484 in make_join_rel (root=0x8566398, rel1=0x85b0490,
rel2=<value optimized out>) at joinrels.c:696
#3 0x082056fe in join_search_one_level (root=0x8566398, level=5,
joinrels=0x85b225c) at joinrels.c:277
#4 0x081f86c3 in standard_join_search (root=0x8566398, levels_needed=5,
initial_rels=0x85b21f0) at allpaths.c:899
#5 0x081f9a9b in make_rel_from_joinlist (root=0x8566398,
joinlist=<value optimized out>) at allpaths.c:836
#6 0x081f9b6b in make_one_rel (root=0x8566398, joinlist=0x85b05f4) at
allpaths.c:97
#7 0x0820e70f in query_planner (root=0x8566398, tlist=0x85ac6f4,
tuple_fraction=0, limit_tuples=-1, cheapest_path=0xbfaac15c,
sorted_path=0xbfaac158, num_groups=0xbfaac150) at planmain.c:252
#8 0x0820fc62 in grouping_planner (root=0x8566398, tuple_fraction=0) at
planner.c:1007
#9 0x082119b0 in subquery_planner (glob=0x85a2c50, parse=0x856603c,
parent_root=0x0, hasRecursion=0 '\0', tuple_fraction=0,
subroot=0xbfaac2a8) at planner.c:482
#10 0x08211f1b in standard_planner (parse=0x856603c, cursorOptions=0,
boundParams=0x0) at planner.c:191
#11 0x0826631f in pg_plan_query (querytree=0x856603c, cursorOptions=0,
boundParams=0x0) at postgres.c:697
#12 0x08266423 in pg_plan_queries (querytrees=0x85a112c,
cursorOptions=0, boundParams=0x0) at postgres.c:756
#13 0x08266cb2 in exec_simple_query (query_string=0x8565244 "SELECT *
FROM table5 WHERE t_id IN ( SELECT pl_value::integer FROM v_view1);")
at postgres.c:920
#14 0x082684f6 in PostgresMain (argc=4, argv=0x850ffc8,
username=0x850ff98 "postgres") at postgres.c:3606
#15 0x08232ea1 in ServerLoop () at postmaster.c:3331
#16 0x08233c0c in PostmasterMain (argc=3, argv=0x84e11c8) at
postmaster.c:1054
#17 0x081d6c97 in main (argc=3, argv=0x84e11c8) at main.c:188

A simple testcase to reproduce might be:

CREATE TABLE table1 (p_id integer, pl_key text, pl_value text);
CREATE TABLE table2 (p_id integer);
CREATE TABLE table3 (sp_id integer, p_id integer, u_id integer);
CREATE TABLE table4 (u_id integer);
CREATE VIEW v_view1 AS
SELECT sp.sp_id, u.u_id, pl.pl_key, CASE WHEN ((pl.pl_key)::text <>
'foobar'::text) THEN pl.pl_value WHEN (((pl.pl_key)::text = 'baz'::text)
AND (u.u_id IN (SELECT sp.u_id FROM table3 sp, table2 p WHERE sp.p_id =
p.p_id))) THEN pl.pl_value ELSE '0'::text END AS pl_value FROM table4 u,
table3 sp, table2 p, table1 pl WHERE ((u.u_id = sp.u_id) AND (sp.p_id =
p.p_id)) AND (p.p_id = pl.p_id);
CREATE TABLE table5 (t_id integer);
SELECT * FROM table5 WHERE t_id IN (SELECT pl_value::integer FROM v_view1);

Stefan