Fix some incorrect preprocessor tests in tuplesort specializations
authorDavid Rowley <drowley@postgresql.org>
Tue, 10 May 2022 23:38:13 +0000 (11:38 +1200)
committerDavid Rowley <drowley@postgresql.org>
Tue, 10 May 2022 23:38:13 +0000 (11:38 +1200)
commitc90c16591c438e4146b1d4b9e4539f80b58845ba
tree26e6edd196336b83e23e25d8f404acbcf643d627
parentaff45c879e018d18951a9bc4cd8e2a395ee52c43
Fix some incorrect preprocessor tests in tuplesort specializations

697492434 added 3 new quicksort specialization functions for common
datatypes.

That commit was not very consistent in how it would determine if we're
compiling for 32-bit or 64-bit machines.  It would sometimes use
USE_FLOAT8_BYVAL and at other times check if SIZEOF_DATUM == 8.  This
could cause theoretical problems due to the way USE_FLOAT8_BYVAL is now
defined based on SIZEOF_VOID_P >= 8.  If pointers for some reason were
ever larger than 8-bytes then we'd end up doing 32-bit comparisons
mistakenly.  Let's just always check SIZEOF_DATUM >= 8.

It also seems that ssup_datum_signed_cmp is just never used on 32-bit
builds, so let's just ifdef that out to make sure we never accidentally
use that comparison function on such machines.  This also allows us to
ifdef out 1 of the 3 new specialization quicksort functions in 32-bit
builds which seems to shrink down the binary by over 4KB on my machine.

In passing, also add the missing DatumGetInt32() / DatumGetInt64() macros
in the comparison functions.

Discussion: https://postgr.es/m/CAApHDvqcQExRhtRa9hJrJB_5egs3SUfOcutP3m+3HO8A+fZTPA@mail.gmail.com
Reviewed-by: John Naylor
src/backend/access/nbtree/nbtcompare.c
src/backend/utils/adt/timestamp.c
src/backend/utils/sort/tuplesort.c
src/include/utils/sortsupport.h