mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-27 08:39:28 +08:00
c87cb5f7a6
Historically we forbade datatype-specific comparison functions from returning INT_MIN, so that it would be safe to invert the sort order just by negating the comparison result. However, this was never really safe for comparison functions that directly return the result of memcmp(), strcmp(), etc, as POSIX doesn't place any such restriction on those library functions. Buildfarm results show that at least on recent Linux on s390x, memcmp() actually does return INT_MIN sometimes, causing sort failures. The agreed-on answer is to remove this restriction and fix relevant call sites to not make such an assumption; code such as "res = -res" should be replaced by "INVERT_COMPARE_RESULT(res)". The same is needed in a few places that just directly negated the result of memcmp or strcmp. To help find places having this problem, I've also added a compile option to nbtcompare.c that causes some of the commonly used comparators to return INT_MIN/INT_MAX instead of their usual -1/+1. It'd likely be a good idea to have at least one buildfarm member running with "-DSTRESS_SORT_INT_MIN". That's far from a complete test of course, but it should help to prevent fresh introductions of such bugs. This is a longstanding portability hazard, so back-patch to all supported branches. Discussion: https://postgr.es/m/20180928185215.ffoq2xrq5d3pafna@alap3.anarazel.de |
||
|---|---|---|
| .. | ||
| data | ||
| expected | ||
| sql | ||
| _ltree_gist.c | ||
| _ltree_op.c | ||
| .gitignore | ||
| crc32.c | ||
| crc32.h | ||
| lquery_op.c | ||
| ltree_gist.c | ||
| ltree_io.c | ||
| ltree_op.c | ||
| ltree--1.0--1.1.sql | ||
| ltree--1.1.sql | ||
| ltree--unpackaged--1.0.sql | ||
| ltree.control | ||
| ltree.h | ||
| ltreetest.sql | ||
| ltxtquery_io.c | ||
| ltxtquery_op.c | ||
| Makefile | ||