wrong Append/MergeAppend elision?

Hi,

It seems that the planner currently elides an Append/MergeAppend that
has run-time pruning info (part_prune_index) set, but which I think is
a bug. Here's an example:

create table p (a int) partition by list (a);
create table p1 partition of p for values in (1);
set plan_cache_mode to force_generic_plan ;
prepare q as select * from p where a = $1;
explain execute q (0);
QUERY PLAN
------------------------------------------------------
Seq Scan on p1 p (cost=0.00..41.88 rows=13 width=4)
Filter: (a = $1)
(2 rows)

Because the Append is elided in this case, run-time pruning doesn't
kick in to prune p1, even though PartitionPruneInfo to do so has been
generated.

Attached find a patch to fix that. There are some expected output
diffs in partition_prune suite, though they all look sane to me.

Thoughts?

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com