Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CAM3SWZSb-mmY1YMrJURjWEh9MVU+i28UOd+q42ko5D=m31EiHg@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Aug 5, 2014 at 12:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> ...but I'm wondering what underlies that decision.   I would
> understand the decision to go that way if it simplified things
> elsewhere, but in fact it seems that's what underlies the addition of
> ssup_operator to SortSupportData, which in turn requires a number of
> changes elsewhere.

The changes aren't too invasive. There is exactly one place where it
isn't a trivial matter of storing the operator that was already
available:

+ /* Original operator must be provided */
+ clause->ssup.ssup_operator = get_opfamily_member(opfamily,
+        op_lefttype,
+        op_righttype,
+        opstrategy);

> So I think it's better to just change the sortsupport contract so that
> filling in the comparator is optional.  Patch for that attached.
> Objections?

I'd have preferred to maintain the obligation for some sane
sortsupport state to be provided. It's not as if I feel too strongly
about it, though.

You attached "git diff --stat" output, and not an actual patch. Please re-send.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)