On Fri, 07 Jan 2022 at 03:21, Tom Lane <t...@sss.pgh.pa.us> wrote: > I looked at this and it does seem like it might work, as per attached > patch. The one thing that is troubling me is that the opclass is set > up to apply gbt_text_same, which is formally the Wrong Thing for bpchar, > because the equality semantics shouldn't be quite the same. But we > could not fix that without a module version bump, which is annoying. > I think that it might not be necessary to change it, because > > (1) There's no such thing as unique GIST indexes, so it should not > matter if the "same" function is a bit stricter than the datatype's > nominal notion of equality. It's certainly okay for that to vary > from the semantics applied by the consistent function --- GIST has > no idea that the consistent function is allegedly testing equality. > > (2) If all the input values for a column have been coerced to the same > typmod, then it doesn't matter because two values that are equal after > space-stripping would be equal without space-stripping, too. > > However, (2) doesn't hold for an existing index that the user has failed > to REINDEX, because then the index would contain some space-stripped > values that same() will not say are equal to incoming new values. > Again, I think this doesn't matter much, but maybe I'm missing > something. I've not really dug into what GIST uses the same() > function for. > > In any case, if we do need same() to implement the identical > behavior to bpchareq(), then the other solution isn't sufficient > either. > > So in short, it seems like we ought to do some compatibility testing > and see if this code misbehaves at all with an index created by the > old code. I don't particularly want to do that ... any volunteers? >
Thanks for your patch, it looks good to me. I'm not sure how to test this. -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
