Pushing IN (subquery) down through UNION ALL?

I'm using PostgreSQL 8.3.3 and I have a view that does a UNION ALL on
two joins and it doesn't seem to want to push the IN (subquery)
optimization down into the plan for the two queries being unioned. Is
there something I can do to fix this? Or is it just a limitation of
the planner/optimizer?

I also tried this with 8.4.7 and it seemed to exhibit the same
behaviour, so here's an example of what I'm talking about (obviously
in a real system I'd have indexes and all that other fun stuff):

CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
CREATE TABLE addresses1 (userid INTEGER, value INTEGER);
CREATE TABLE addresses1 (userid INTEGER, value INTEGER);
CREATE VIEW addressesall AS SELECT u.id, u.name, a.value FROM
addresses1 AS a JOIN users AS u ON a.userid=u.id UNION ALL SELECT
u.id, u.name, a.value FROM addresses2 AS a JOIN users AS u ON
a.userid=u.id;

Here's the EXPLAIN output for two example queries:

test=# EXPLAIN ANALYZE SELECT * FROM addressesall WHERE id IN (SELECT
id FROM users WHERE name='A');
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Hash Semi Join (cost=2.15..5.58 rows=1 width=40) (actual
time=0.144..0.340 rows=3 loops=1)
Hash Cond: (u.id = users.id)
-> Append (cost=1.09..4.48 rows=9 width=40) (actual
time=0.059..0.239 rows=9 loops=1)
-> Hash Join (cost=1.09..2.19 rows=4 width=10) (actual
time=0.055..0.075 rows=4 loops=1)
Hash Cond: (a.userid = u.id)
-> Seq Scan on addresses1 a (cost=0.00..1.04 rows=4
width=8) (actual time=0.006..0.013 rows=4 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=6) (actual
time=0.019..0.019 rows=4 loops=1)
-> Seq Scan on users u (cost=0.00..1.04 rows=4
width=6) (actual time=0.003..0.008 rows=4 loops=1)
-> Hash Join (cost=1.09..2.21 rows=5 width=10) (actual
time=0.109..0.133 rows=5 loops=1)
Hash Cond: (a.userid = u.id)
-> Seq Scan on addresses2 a (cost=0.00..1.05 rows=5
width=8) (actual time=0.004..0.012 rows=5 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=6) (actual
time=0.020..0.020 rows=4 loops=1)
-> Seq Scan on users u (cost=0.00..1.04 rows=4
width=6) (actual time=0.004..0.010 rows=4 loops=1)
-> Hash (cost=1.05..1.05 rows=1 width=4) (actual
time=0.053..0.053 rows=1 loops=1)
-> Seq Scan on users (cost=0.00..1.05 rows=1 width=4)
(actual time=0.032..0.040 rows=1 loops=1)
Filter: (name = 'A'::text)
Total runtime: 0.519 ms
(17 rows)

test=# EXPLAIN ANALYZE SELECT * FROM addressesall WHERE id IN (SELECT
id FROM users WHERE name='A');
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Hash Semi Join (cost=2.15..5.58 rows=1 width=40) (actual
time=0.144..0.340 rows=3 loops=1)
Hash Cond: (u.id = users.id)
-> Append (cost=1.09..4.48 rows=9 width=40) (actual
time=0.059..0.239 rows=9 loops=1)
-> Hash Join (cost=1.09..2.19 rows=4 width=10) (actual
time=0.055..0.075 rows=4 loops=1)
Hash Cond: (a.userid = u.id)
-> Seq Scan on addresses1 a (cost=0.00..1.04 rows=4
width=8) (actual time=0.006..0.013 rows=4 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=6) (actual
time=0.019..0.019 rows=4 loops=1)
-> Seq Scan on users u (cost=0.00..1.04 rows=4
width=6) (actual time=0.003..0.008 rows=4 loops=1)
-> Hash Join (cost=1.09..2.21 rows=5 width=10) (actual
time=0.109..0.133 rows=5 loops=1)
Hash Cond: (a.userid = u.id)
-> Seq Scan on addresses2 a (cost=0.00..1.05 rows=5
width=8) (actual time=0.004..0.012 rows=5 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=6) (actual
time=0.020..0.020 rows=4 loops=1)
-> Seq Scan on users u (cost=0.00..1.04 rows=4
width=6) (actual time=0.004..0.010 rows=4 loops=1)
-> Hash (cost=1.05..1.05 rows=1 width=4) (actual
time=0.053..0.053 rows=1 loops=1)
-> Seq Scan on users (cost=0.00..1.05 rows=1 width=4)
(actual time=0.032..0.040 rows=1 loops=1)
Filter: (name = 'A'::text)
Total runtime: 0.519 ms
(17 rows)

test=# EXPLAIN ANALYZE SELECT * FROM addressesall WHERE id IN (1);
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Result (cost=0.00..4.27 rows=3 width=40) (actual time=0.053..0.114
rows=3 loops=1)
-> Append (cost=0.00..4.27 rows=3 width=40) (actual
time=0.049..0.101 rows=3 loops=1)
-> Nested Loop (cost=0.00..2.12 rows=2 width=10) (actual
time=0.046..0.063 rows=2 loops=1)
-> Seq Scan on users u (cost=0.00..1.05 rows=1
width=6) (actual time=0.025..0.028 rows=1 loops=1)
Filter: (id = 1)
-> Seq Scan on addresses1 a (cost=0.00..1.05 rows=2
width=8) (actual time=0.009..0.017 rows=2 loops=1)
Filter: (a.userid = 1)
-> Nested Loop (cost=0.00..2.12 rows=1 width=10) (actual
time=0.015..0.025 rows=1 loops=1)
-> Seq Scan on addresses2 a (cost=0.00..1.06 rows=1
width=8) (actual time=0.005..0.008 rows=1 loops=1)
Filter: (userid = 1)
-> Seq Scan on users u (cost=0.00..1.05 rows=1
width=6) (actual time=0.004..0.007 rows=1 loops=1)
Filter: (u.id = 1)
Total runtime: 0.251 ms
(13 rows)

You'll notice that the subquery version is doing the full join and
then the filtering, but the explicitly listed version pushing the
filtering into the plan before the join. Is there a way to make the
subquery version perform the same optimization?

Thanks,
Dave