summaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2015-01-27 12:06:31 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2015-01-27 12:06:31 -0500
commit1a2b2034d48d46ec3d128b167cb7df317b4cd49a (patch)
tree101fd6d80ddd5ceff4d92a2602460f162efd7bdd /src/backend/access/gist/gistproc.c
parent4b2a254793be50e31d43d4bfd813da8d141494b8 (diff)
downloadpostgresql-1a2b2034d48d46ec3d128b167cb7df317b4cd49a.tar.gz
Fix NUMERIC field access macros to treat NaNs consistently.
Commit 145343534c153d1e6c3cff1fa1855787684d9a38 arranged to store numeric NaN values as short-header numerics, but the field access macros did not get the memo: they thought only "SHORT" numerics have short headers. Most of the time this makes no difference because we don't access the weight or dscale of a NaN; but numeric_send does that. As pointed out by Andrew Gierth, this led to fetching uninitialized bytes. AFAICS this could not have any worse consequences than that; in particular, an unaligned stored numeric would have been detoasted by PG_GETARG_NUMERIC, so that there's no risk of a fetch off the end of memory. Still, the code is wrong on its own terms, and it's not hard to foresee future changes that might expose us to real risks. So back-patch to all affected branches.
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions