On Thu, Oct 31, 2019 at 9:36 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > float8 and related types are now hardcoded to pass-by-value or > > pass-by-reference depending on whether the build is 64- or 32-bit, as > > was previously also the default. > > I'm less happy with doing this. It makes it impossible to test the > pass-by-reference code paths without actually firing up a 32-bit > environment. It'd be fine to document --disable-float8-byval as > a developer-only option (it might be so already), but I don't want > to lose it completely. I fail to see any advantage in getting rid > of it, anyway, since we do still have to maintain both code paths.
Could we get around this by making Datum 8 bytes everywhere? Years ago, we got rid of INT64_IS_BUSTED, so we're relying on 64-bit types working on all platforms. However, Datum on a system where pointers are only 32 bits wide is also only 32 bits wide, so we can't pass 64-bit quantities the same way we do elsewhere. But, why is the width of a Datum equal to the width of a pointer, anyway? It would surely cost something to widen 1, 2, and 4 byte quantities to 8 bytes when packing them into datums on 32-bit platforms, but (1) we've long since accepted that cost on 64-bit platforms, (2) it would save palloc/pfree cycles when packing 8 byte quantities into 4-byte values, (3) 32-bit platforms are now marginal and performance on those platforms is not critical, and (4) it would simplify a lot of code and reduce future bugs. On a related note, why do we store typbyval in the catalog anyway instead of inferring it from typlen and maybe typalign? It seems like a bad idea to record on disk the way we pass around values in memory, because it means that a change to how values are passed around in memory has ramifications for on-disk compatibility. rhaas=# select typname, typlen, typbyval, typalign from pg_type where typlen in (1,2,4,8) != typbyval; typname | typlen | typbyval | typalign ----------+--------+----------+---------- macaddr8 | 8 | f | i (1 row) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
