Re: B-Tree support function number 3 (strxfrm() optimization)

On Wed, Jul 30, 2014 at 3:04 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> I don't have a problem with changing the name. But the name that you
> propose is all about text. This patch is intended to add an extensible
> infrastructure (a new part of sort support), plus one client of that
> more complete extensible infrastructure (sort support for text). I
> think there's a good chance that it could work well for another type
> too, like numeric, if we could come up with a good system for encoding
> numeric normalized keys, and if we can similarly get over the fact
> that there is going to be a minority of cases that won't be helped at
> all. That's a whole other discussion, though, and text is clearly the
> really compelling case.
>
> Do you have another suggestion?

How about "proxy sort keys"? It's suggestive of a format that can be
relied on to faithfully represent the original key. But, like any
proxy, it's a substitute, and by definition a substitute is never as
authoritative as the original value. As such, the original value may
need to be consulted when the proxy sort key doesn't have enough
information to give a conclusive answer, which hopefully doesn't
happen often. Like any good proxy, proxy sort keys know enough to know
when they cannot faithfully represent what the original value would
say. In practice proxy sort keys are almost always themselves
pass-by-value, while serving to proxy a pass by reference type, but
this isn't a formal requirement. Encoding strategies don't necessarily
have anything to do with strxfrm(). That's just how text's default
opclass happens to do it.

--
Peter Geoghegan