summaryrefslogtreecommitdiff
path: root/contrib/btree_gist/btree_ts.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-08-13 17:11:54 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2025-08-13 17:18:22 -0400
commit6aebedc38497ecebda22caf61bcadf78a8331b52 (patch)
tree2db3fe53e46ba28e07ad6721773685f57e3ee9fa /contrib/btree_gist/btree_ts.c
parent2a600a93c7be5b0bf8cacb1af78009db12bc4857 (diff)
Grab the low-hanging fruit from forcing sizeof(Datum) to 8.
Remove conditionally-compiled code for smaller Datum widths, and simplify comments that describe cases no longer of interest. I also fixed up a few more places that were not using DatumGetIntXX where they should, and made some cosmetic adjustments such as using sizeof(int64) not sizeof(Datum) in places where that fit better with the surrounding code. One thing I remembered while preparing this part is that SP-GiST stores pass-by-value prefix keys as Datums, so that the on-disk representation depends on sizeof(Datum). That's even more unfortunate than the existing commentary makes it out to be, because now there is a hazard that the change of sizeof(Datum) will break SP-GiST indexes on 32-bit machines. It appears that there are no existing SP-GiST opclasses that are actually affected; and if there are some that I didn't find, the number of installations that are using them on 32-bit machines is doubtless tiny. So I'm proceeding on the assumption that we can get away with this, but it's something to worry about. (gininsert.c looks like it has a similar problem, but it's okay because the "tuples" it's constructing are just transient data within the tuplesort step. That's pretty poorly documented though, so I added some comments.) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/1749799.1752797397@sss.pgh.pa.us
Diffstat (limited to 'contrib/btree_gist/btree_ts.c')
0 files changed, 0 insertions, 0 deletions