On Thu, Oct 3, 2024 at 4:15 PM Peter Geoghegan <p...@bowt.ie> wrote:
> Now that you're explicitly creating RestrictInfos for a particular
> index, I suppose that it might be easier to do this kind of thing --
> you have more context. Perhaps the patch can be made to recognize
> a mix of constants like this as all being associated with the same
> B-Tree operator family (the opfamily that the input opclass belongs
> to)? Perhaps the constants could all be normalized to the same type via
> casts/coercions into the underlying B-Tree input opclass -- that
> extra step should be correct ("64.1.2. Behavior of B-Tree Operator Classes"
> describes certain existing guarantees that this step would need to rely
> on).I don't think you can convert everything to the same type because we have to assume that type conversions can fail. An exception is if the types are binary-compatible but that's not the case here. If there's a way to fix this problem, it's probably by doing the first thing you suggest above: noticing that all the constants belong to the same opfamily. I'm not sure if that approach can work either, but I think it has better chances. Personally, I don't think this particular limitation is a problem. I don't think it will be terribly frequent in practice, and it doesn't seem any weirder than any of the other things that happen as a result of small and large integer constants being differently typed. -- Robert Haas EDB: http://www.enterprisedb.com
