On 2018/03/02 21:43, Robert Haas wrote: > On Fri, Mar 2, 2018 at 1:22 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> But I realized we don't need the coercion. Earlier steps would have >> determined that the clause from which the expression originated contains >> an operator that is compatible with the partitioning operator family. If >> so, the type of the expression in question, even though different from the >> partition key type, would be binary coercible with it. > > That doesn't follow. Knowing that two types are in the same operator > family doesn't guarantee that the types are binary coercible. For > example, int8 is not binary-coercible to int2. Moreover, you'd better > be pretty careful about trying to cast int8 to int2 because it might > turn a query that would have returned no rows into one that fails > outright; that's not OK. Imagine that the user types: > > SELECT * FROM partitioned_by_int2 WHERE a = 1000000000000; > > I think what needs to happen with cross-type situations is that you > look in the opfamily for a comparator that takes the types you want as > input; if you can't find one, you have to give up on pruning. If you > do find one, then you use it. For example in the above query, once > you find btint28cmp, you can use that to compare the user-provided > constant against the range bounds for the various partitions to see > which one might contain it. You'll end up selecting the partition > with upper bound MAXVALUE if there is one, or no partition at all if > every partition has a finite upper bound. That's as well as we can do > with current infrastructure, I think.
Hmm, yes. So while the patch's previous approach to convert the query's constant value to the desired type was wrong, this is wronger. :-( I guess I'll need to change the patch such that the comparison function used for comparing partition bounds with a query-specified constant will change from the default one from the PartitionKey to the one that accepts the latter. Thanks, Amit