Re: inconsistent results querying table partitioned by date

On Wed, 15 May 2019 at 08:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So I think David's got the right idea that match_clause_to_partition_key
> is where to handle this, and I like the fact that his patch explicitly
> represents whether we're trying to do run-time or plan-time pruning.
> I agree it's kind of invasive, and I wonder why. Shouldn't the
> additional flag just be a field in the "context" struct, instead of
> being a separate parameter that has to be laboriously passed through
> many call levels?

Thanks for having a look. I originally stayed clear of "context"
since it looks more like how we output the pruning steps, rather than
a context as to how they should be generated. But it's true, using it
saves having to pass the extra argument around, so I made that change.

> (For myself, I'd have made it just a bool not an enum, given that
> I don't foresee a need for additional values. But that's definitely
> a matter of preference.)

I've changed to bool, mostly because it makes the patch a bit smaller.

> Also, I'm a bit confused by the fact that we seem to have a bunch
> of spare-parts patches in this thread. What combination is actually
> being proposed for commit?

I was also confused at the extra two patches Amit posted. The extra
one for the tests didn't look very valid to me, as I mentioned
yesterday.

I propose the attached for master, and I'll post something for v11 shortly.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services