Andres Freund <and...@anarazel.de> writes:
> On June 5, 2019 12:14:42 PM PDT, Alvaro Herrera <alvhe...@2ndquadrant.com>
> wrote:
>> Does this mean that datatypes that are >4 and <=8 bytes need to handle
>> both cases? Is it possible for them to detect the current environment?
> Well, the conversion macros need to know. You can look at float8 for an
> example of the difference - it's pretty centralized. We should provide a few
> helper macros to abstract that away.
FWIW, I disagree with Andres on this being a reasonable way to proceed.
The fact that we support both pass-by-value and pass-by-ref for float8
and int8 is because those are important data types that are worth taking
extra pains to optimize. It's a very long way from there to insisting
that every datatype between 5 and 8 bytes long must get the same
treatment, and even further to Andres' apparent position that we should
force third-party types to do it whether they care about
micro-optimization or not.
And I *entirely* fail to get the point of adding such support for
datatypes of 5 or 7 bytes. No such types exist, or are on the horizon
AFAIK.
Lastly, I don't think adding additional allowed widths of pass-by-value
types would be cost-free, because it would add cycles to the inner loops
of the tuple forming and deforming functions. (No, I don't believe that
JIT makes that an ignorable concern.)
I'm not really sure that either macaddr or macaddr8 are used widely
enough to justify expending optimization effort on them. But if they
are, let's just do that, not move the goal posts into the next stadium.
regards, tom lane
