On Wed, Jul 30, 2014 at 7:17 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Jul 30, 2014 at 3:04 PM, Peter Geoghegan <pg@heroku.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.
I certainly like that better than poor-man; but proxy, to me, fails to
convey inexactness. Perhaps we can work that idea in somehow. Or
maybe "pre"-something, to indicate that we do this before comparing
the regular key, in the hopes of not needing to.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
