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

On Wed, Jan 21, 2015 at 2:11 PM, Peter Geoghegan <pg@heroku.com> wrote:
> Okay, then. I concede the point: We should support the datum case as
> you outline, since it is simpler than any alternative. It probably
> won't even be necessary to formalize the idea that finished
> abbreviated keys must be pass-by-value (at least not for the benefit
> of this functionality); if someone writes an opclass that generates
> pass-by-reference abbreviated keys (I think that might actually make
> sense, although I'm being imaginative), it simply won't work for the
> datum sort case, which is probably fine.

I mean that a restriction formally preventing use of abbreviation with
pass-by-value types isn't necessary. That was something that I thought
we'd have to document as a restriction (for the benefit of your datum
sort patch), without considering that it could simply be skipped by
only considering state->datumTypeByVal (which is what you've proposed
here).

This requirement is much less likely than wanting to create
pass-by-value abbreviated keys for a pass-by-value datatype (which, as
I go into above, seems at least possible). This seems like a very
insignificant restriction, not worth formalizing or even mentioning in
code comments.

-- 
Peter Geoghegan