On Thu, 31 Oct 2019 at 17:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <david.rowley@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
