postgresql/contrib/ltree/crc32.c

/* contrib/ltree/crc32.c */

/*
 * Implements CRC-32, as used in ltree.
 *
 * Note that the CRC is used in the on-disk format of GiST indexes, so we
 * must stay backwards-compatible!
 */

#include "postgres.h"

#ifdef LOWER_NODE
#include <ctype.h>
#define TOLOWER(x)	tolower((unsigned char) (x))
#else
#define TOLOWER(x)	(x)
#endif

#include "crc32.h"
#include "utils/pg_crc.h"

unsigned int
ltree_crc32_sz(char *buf, int size)
{
	pg_crc32	crc;
	char	   *p = buf;

	INIT_TRADITIONAL_CRC32(crc);
	while (size > 0)
	{
		char		c = (char) TOLOWER(*p);

		COMP_TRADITIONAL_CRC32(crc, &c, 1);
		size--;
		p++;
	}
	FIN_TRADITIONAL_CRC32(crc);
	return (unsigned int) crc;
}
Remove cvs keywords from all files. 2010-09-21 04:08:53 +08:00			`/* contrib/ltree/crc32.c */`
Add CVS tag lines to files that were lacking them. 2006-03-11 12:38:42 +08:00
Switch to CRC-32C in WAL and other places. 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. 2014-11-04 17:35:15 +08:00			`/*`
			`* Implements CRC-32, as used in ltree.`
			`*`
			`* Note that the CRC is used in the on-disk format of GiST indexes, so we`
			`* must stay backwards-compatible!`
			`*/`

Add postgres.h to .c files for pg_upgrade, ltree, and btree_gist, and remove from local .h files. Per suggestion from Alvaro. 2011-08-27 09:16:24 +08:00			`#include "postgres.h"`

Add ltree data type to contrib, from Teodor Sigaev and Oleg Bartunov. 2002-07-31 00:40:34 +08:00			`#ifdef LOWER_NODE`
			`#include <ctype.h>`
Fix bugs in plpgsql and ecpg caused by assuming that isspace() would only return true for exactly the characters treated as whitespace by their flex scanners. Per report from Victor Snezhko and subsequent investigation. Also fix a passel of unsafe usages of <ctype.h> functions, that is, ye olde char-vs-unsigned-char issue. I won't miss <ctype.h> when we are finally able to stop using it. 2006-09-23 05:39:58 +08:00			`#define TOLOWER(x) tolower((unsigned char) (x))`
Add ltree data type to contrib, from Teodor Sigaev and Oleg Bartunov. 2002-07-31 00:40:34 +08:00			`#else`
			`#define TOLOWER(x) (x)`
			`#endif`

			`#include "crc32.h"`
Make the order of the header file includes consistent in contrib modules. The basic rule we follow here is to always first include 'postgres.h' or 'postgres_fe.h' whichever is applicable, then system header includes and then Postgres header includes. In this, we also follow that all the Postgres header includes are in order based on their ASCII value. We generally follow these rules, but the code has deviated in many places. This commit makes it consistent just for contrib modules. The later commits will enforce similar rules in other parts of code. Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com 2019-10-23 11:56:22 +08:00			`#include "utils/pg_crc.h"`
Add ltree data type to contrib, from Teodor Sigaev and Oleg Bartunov. 2002-07-31 00:40:34 +08:00
			`unsigned int`
Fixed very stupid but important bug: mixing calls of some founctions from contrib/tsearch and contrib/ltree :) Teodor Sigaev 2002-08-11 04:46:24 +08:00			`ltree_crc32_sz(char *buf, int size)`
Add ltree data type to contrib, from Teodor Sigaev and Oleg Bartunov. 2002-07-31 00:40:34 +08:00			`{`
pgindent run for 9.5 2015-05-24 09:35:49 +08:00			`pg_crc32 crc;`
Switch to CRC-32C in WAL and other places. 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. 2014-11-04 17:35:15 +08:00			`char *p = buf;`

			`INIT_TRADITIONAL_CRC32(crc);`
			`while (size > 0)`
			`{`
pgindent run for 9.5 2015-05-24 09:35:49 +08:00			`char c = (char) TOLOWER(*p);`

Switch to CRC-32C in WAL and other places. 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. 2014-11-04 17:35:15 +08:00			`COMP_TRADITIONAL_CRC32(crc, &c, 1);`
			`size--;`
			`p++;`
			`}`
			`FIN_TRADITIONAL_CRC32(crc);`
			`return (unsigned int) crc;`
Add ltree data type to contrib, from Teodor Sigaev and Oleg Bartunov. 2002-07-31 00:40:34 +08:00			`}`