Re: inconsistent results querying table partitioned by date

I wrote:
> In other words, as I compose this I'm talking myself into the
> idea that invoking gen_partprune_steps three times (for planner,
> executor startup, and executor runtime, with corresponding
> filters on which clauses can be used) is the only safe near-term
> fix. In the future we can look at cutting down the repetitive
> costs that entails.

Here's a really quick and dirty POC along that line. It's unfinished
but I'm out of time for today. I think the executor side of it is OK,
but the planner side is crufty: it lacks logic to decide whether
either the initial pruning or exec pruning steps are unnecessary.
And I didn't update most of the comments either.

I think the rule for "exec pruning is unnecessary" could probably
just be "we didn't find any exec params in the prune steps", since
that would imply that the initial steps include everything.
I don't see an equally cheap way to decide that initial pruning
is useless, though. Thoughts?

Also, it seems like we could save at least some of the planning expense by
having the PARTCLAUSE_INITIAL pass report back whether it had discarded
any Param-bearing clauses or not. If not, there's definitely no need to
run the PARTCLAUSE_EXEC pass.

regards, tom lane