key = currval('tab_key_seq') choses SEQSCAN?!

I have a large table (named "changes") which is perfectly willing to
support index lookups when its primary key (named "change") is
compared to a constant integer:

# explain select * from changes where change = 42;
QUERY PLAN
-----------------------------------------------------------------------------
Index Scan using changes_pkey on changes (cost=0.00..3.01 rows=1 width=78)
Index Cond: (change = 42)
(2 rows)

But this same table suddenly becomes unwilling to use an index scan if
the target value is the result of the currval() function:

# explain select * from changes where change = currval('changes_change_seq');
QUERY PLAN
----------------------------------------------------------
Seq Scan on changes (cost=0.00..323.21 rows=1 width=78)
Filter: (change = currval('changes_change_seq'::text))
(2 rows)

Explicitly casting the result of currval() to an integer (of any size)
does not seem improve the situation. Is my expectation unreasonable
that the planner should consider the result of an INTEGER CAST in the
same way it considers a literal integer?

--
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech brandon(at)oit(dot)gatech(dot)edu