On Thu, 31 Oct 2019 at 17:56, Tom Lane <t...@sss.pgh.pa.us> wrote: > > David Rowley <david.row...@2ndquadrant.com> writes: > > In Ottawa this year, Andres and I briefly talked about the possibility > > of making a series of changes to how equalfuncs.c works. The idea was > > to make it easy by using some pre-processor magic to allow us to > > create another version of equalfuncs which would let us have an equal > > comparison function that returns -1 / 0 / +1 rather than just true or > > false. This would allow us to Binary Search Trees of objects. I > > identified that EquivalenceClass.ec_members would be better written as > > a BST to allow much faster lookups in get_eclass_for_sort_expr(). > > This seems like a good idea, but why would we want to maintain two > versions? Just change equalfuncs.c into comparefuncs.c, full stop. > equal() would be a trivial wrapper for (compare_objects(a,b) == 0).
If we can do that without slowing down the comparison, then sure. Checking which node sorts earlier is a bit more expensive than just checking for equality. But if that's not going to be noticeable in real-world test cases, then I agree. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
