5028f22f6e
The old algorithm was found to not be the usual CRC-32 algorithm, used by Ethernet et al. We were using a non-reflected lookup table with code meant for a reflected lookup table. That's a strange combination that AFAICS does not correspond to any bit-wise CRC calculation, which makes it difficult to reason about its properties. Although it has worked well in practice, seems safer to use a well-known algorithm. Since we're changing the algorithm anyway, we might as well choose a different polynomial. The Castagnoli polynomial has better error-correcting properties than the traditional CRC-32 polynomial, even if we had implemented it correctly. Another reason for picking that is that some new CPUs have hardware support for calculating CRC-32C, but not CRC-32, let alone our strange variant of it. This patch doesn't add any support for such hardware, but a future patch could now do that. The old algorithm is kept around for tsquery and pg_trgm, which use the values in indexes that need to remain compatible so that pg_upgrade works. While we're at it, share the old lookup table for CRC-32 calculation between hstore, ltree and core. They all use the same table, so might as well.
24 lines
582 B
Makefile
24 lines
582 B
Makefile
# contrib/hstore/Makefile
|
|
|
|
MODULE_big = hstore
|
|
OBJS = hstore_io.o hstore_op.o hstore_gist.o hstore_gin.o hstore_compat.o \
|
|
$(WIN32RES)
|
|
|
|
EXTENSION = hstore
|
|
DATA = hstore--1.3.sql hstore--1.2--1.3.sql \
|
|
hstore--1.1--1.2.sql hstore--1.0--1.1.sql \
|
|
hstore--unpackaged--1.0.sql
|
|
PGFILEDESC = "hstore - key/value pair data type"
|
|
|
|
REGRESS = hstore
|
|
|
|
ifdef USE_PGXS
|
|
PG_CONFIG = pg_config
|
|
PGXS := $(shell $(PG_CONFIG) --pgxs)
|
|
include $(PGXS)
|
|
else
|
|
subdir = contrib/hstore
|
|
top_builddir = ../..
|
|
include $(top_builddir)/src/Makefile.global
|
|
include $(top_srcdir)/contrib/contrib-global.mk
|
|
endif
|