18 Commits (6db75edb2ecbc9f6912f90b671b01ab4ac3a01b0)

Author	SHA1	Message	Date
David Rowley	245de48455	Adjust MSVC build scripts to parse Makefiles for defines ... This adjusts the MSVC build scripts to look at the compile flags mentioned in the Makefile to look for -D arguments in order to determine which constants should be defined in Visual Studio builds. One small anomaly that appeared as a result of this change is that the Makefile for the ltree contrib module defined LOWER_NODE, but this was not properly defined in the MSVC build scripts. This meant that MSVC builds would differ in case sensitivity in the ltree module when compared to builds using a make build environment. To maintain the same behavior here we remove the -DLOWER_NODE from the Makefile and just always define it in ltree.h for non-MSVC builds. We need to maintain the old behavior here as this affects the on-disk compatibility of GiST indexes when using the ltree type. The only other resulting change here is that REFINT_VERBOSE is now defined for the autoinc, insert_username and moddatetime contrib modules. Previously on MSVC, this was only defined for the refint module. This aligns the behavior to build environments using make as all 4 of these modules share the same Makefile. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAApHDvpo6g5csCTjc_0C7DMvgFPomVb0Rh-AcW5afd=Ya=LRuw@mail.gmail.com	4 years ago
Tom Lane	949a9f043e	Add support for binary I/O of ltree, lquery, and ltxtquery types. ... Not much to say here --- does what it says on the tin. The "binary" representation in each case is really just the same as the text format, though we prefix a version-number byte in case anyone ever feels motivated to change that. Thus, there's not any expectation of improved speed or reduced space; the point here is just to allow clients to use binary format for all columns of a query result or COPY data. This makes use of the recently added ALTER TYPE support to add binary I/O functions to an existing data type. As in commit a80818605, we can piggy-back on there already being a new-for-v13 version of the ltree extension, so we don't need a new update script file. Nino Floris, reviewed by Alexander Korotkov and myself Discussion: https://postgr.es/m/CANmj9Vxx50jOo1L7iSRxd142NyTz6Bdcgg7u9P3Z8o0=HGkYyQ@mail.gmail.com	6 years ago
Amit Kapila	7e735035f2	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	6 years ago
Tom Lane	9e3755ecb2	Remove useless duplicate inclusions of system header files. ... c.h #includes a number of core libc header files, such as <stdio.h>. There's no point in re-including these after having read postgres.h, postgres_fe.h, or c.h; so remove code that did so. While at it, also fix some places that were ignoring our standard pattern of "include postgres[_fe].h, then system header files, then other Postgres header files". While there's not any great magic in doing it that way rather than system headers last, it's silly to have just a few files deviating from the general pattern. (But I didn't attempt to enforce this globally, only in files I was touching anyway.) I'd be the first to say that this is mostly compulsive neatnik-ism, but over time it might save enough compile cycles to be useful.	9 years ago
Bruce Momjian	807b9e0dff	pgindent run for 9.5	10 years ago
Heikki Linnakangas	4f700bcd20	Reorganize our CRC source files again. ... Now that we use CRC-32C in WAL and the control file, the "traditional" and "legacy" CRC-32 variants are not used in any frontend programs anymore. Move the code for those back from src/common to src/backend/utils/hash. Also move the slicing-by-8 implementation (back) to src/port. This is in preparation for next patch that will add another implementation that uses Intel SSE 4.2 instructions to calculate CRC-32C, where available.	11 years ago
Heikki Linnakangas	c619c2351f	Move pg_crc.c to src/common, and remove pg_crc_tables.h ... To get CRC functionality in a client program, you now need to link with libpgcommon instead of libpgport. The CRC code has nothing to do with portability, so libpgcommon is a better home. (libpgcommon didn't exist when pg_crc.c was originally moved to src/port.) Remove the possibility to get CRC functionality by just #including pg_crc_tables.h. I'm not aware of any extensions that actually did that and couldn't simply link with libpgcommon. This also moves the pg_crc.h header file from src/include/utils to src/include/common, which will require changes to any external programs that currently does #include "utils/pg_crc.h". That seems acceptable, as include/common is clearly the right home for it now, and the change needed to any such programs is trivial.	11 years ago
Heikki Linnakangas	5028f22f6e	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.	11 years ago
Bruce Momjian	f1312b5ed3	Add postgres.h to *.c files for pg_upgrade, ltree, and btree_gist, and ... remove from local *.h files. Per suggestion from Alvaro.	14 years ago
Magnus Hagander	9f2e211386	Remove cvs keywords from all files.	15 years ago
Tom Lane	af18d3d05c	Fix compile warning on Solaris, per buildfarm. (Why have we got ... three slightly different copies of this file?)	18 years ago
Tom Lane	beca984e5f	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.	19 years ago
Bruce Momjian	f3d99d160d	Add CVS tag lines to files that were lacking them.	20 years ago
Bruce Momjian	b492c3accc	Add parentheses to macros when args are used in computations. Without ... them, the executation behavior could be unexpected.	21 years ago
Bruce Momjian	e50f52a074	pgindent run.	23 years ago
Bruce Momjian	87cfb8eb29	Fixed very stupid but important bug: mixing calls of some founctions from ... contrib/tsearch and contrib/ltree :) Teodor Sigaev	23 years ago
Bruce Momjian	be2de3b9c8	The patch solves this problem, I hope... ... Christopher Kings-Lynne wrote: > I'm still getting ltree failures on 64bit freebsd: > > sed 's,MODULE_PATHNAME,$libdir/ltree,g' ltree.sql.in >ltree.sql > gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI > C -DLOWER_NODE -I. -I../../src/include -c -o ltree_io.o ltree_io.c -MMD > ltree_io.c: In function `ltree_in': > ltree_io.c:57: warning: int format, different type arg (arg 3) > ltree_io.c:63: warning: int format, different type arg (arg 4) > ltree_io.c:68: warning: int format, different type arg (arg 3) Teodor Sigaev	23 years ago
Bruce Momjian	1dedbf2da5	Add ltree data type to contrib, from Teodor Sigaev and Oleg Bartunov.	23 years ago
Bruce Momjian	b81844b173	pgindent run on all C files. Java run to follow. initdb/regression ... tests pass.	24 years ago
Tom Lane	b57705673d	txtidx datatype for full text indexing with GiST. ... From Oleg Bartunov and Teodor Sigaev.	24 years ago