Re: B-Tree support function number 3 (strxfrm() optimization)
От | Peter Geoghegan |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CAM3SWZSb-mmY1YMrJURjWEh9MVU+i28UOd+q42ko5D=m31EiHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: