On Wed, Jan 21, 2015 at 2:11 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
