aboutsummaryrefslogtreecommitdiff
path: root/contrib/intarray
Commit message (Collapse)AuthorAge
* Update extensions with GIN/GIST support for parallel query.Robert Haas2016-06-14
| | | | | | | | | | | | | | | | | | | | Commit 749a787c5b25ae33b3d4da0ef12aa05214aa73c7 bumped the extension version on all of these extensions already, and we haven't had a release since then, so we can make further changes without bumping the extension version again. Take this opportunity to mark all of the functions exported by these modules PARALLEL SAFE -- except for pg_trgm's set_limit(). Mark that one PARALLEL RESTRICTED, because it makes a persistent change to a GUC value. Note that some of the markings added by this commit don't have any effect; for example, gseg_picksplit() isn't likely to be mentioned explicitly in a query and therefore it's parallel-safety marking will never be consulted. But this commit just marks everything for consistency: if it were somehow used in a query, that would be fine as far as parallel query is concerned, since it does not consult any backend-private state, attempt to write data, etc. Andreas Karlsson, with a few revisions by me.
* Handle contrib's GIN/GIST support function signature changes honestly.Tom Lane2016-06-09
| | | | | | | | | | | | | | | In commits 9ff60273e35cad6e and dbe2328959e12701 I (tgl) fixed the signatures of a bunch of contrib's GIN and GIST support functions so that they would pass validation by the recently-added amvalidate functions. The backend does not actually consult or check those signatures otherwise, so I figured this was basically cosmetic and did not require an extension version bump. However, Alexander Korotkov pointed out that that would leave us in a pretty messy situation if we ever wanted to redefine those functions later, because there wouldn't be a unique way to name them. Since we're going to be bumping these extensions' versions anyway for parallel-query cleanups, let's take care of this now. Andreas Karlsson, adjusted for more search-path-safety by me
* Fix assorted inconsistencies in GIN opclass support function declarations.Tom Lane2016-01-19
| | | | | | | | | | | GIN had some minor issues too, mostly using "internal" where something else would be more appropriate. I went with the same approach as in 9ff60273e35cad6e, namely preferring the opclass' indexed datatype for arguments that receive an operator RHS value, even if that's not necessarily what they really are. Again, this is with an eye to having a uniform rule for ginvalidate() to check support function signatures.
* Fix assorted inconsistencies in GiST opclass support function declarations.Tom Lane2016-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The conventions specified by the GiST SGML documentation were widely ignored. For example, the strategy-number argument for "consistent" and "distance" functions is specified to be a smallint, but most of the built-in support functions declared it as an integer, and for that matter the core code passed it using Int32GetDatum not Int16GetDatum. None of that makes any real difference at runtime, but it's quite confusing for newcomers to the code, and it makes it very hard to write an amvalidate() function that checks support function signatures. So let's try to instill some consistency here. Another similar issue is that the "query" argument is not of a single well-defined type, but could have different types depending on the strategy (corresponding to search operators with different righthand-side argument types). Some of the functions threw up their hands and declared the query argument as being of "internal" type, which surely isn't right ("any" would have been more appropriate); but the majority position seemed to be to declare it as being of the indexed data type, corresponding to a search operator with both input types the same. So I've specified a convention that that's what to do always. Also, the result of the "union" support function actually must be of the index's storage type, but the documentation suggested declaring it to return "internal", and some of the functions followed that. Standardize on telling the truth, instead. Similarly, standardize on declaring the "same" function's inputs as being of the storage type, not "internal". Also, somebody had forgotten to add the "recheck" argument to both the documentation of the "distance" support function and all of their SQL declarations, even though the C code was happily using that argument. Clean that up too. Fix up some other omissions in the docs too, such as documenting that union's second input argument is vestigial. So far as the errors in core function declarations go, we can just fix pg_proc.h and bump catversion. Adjusting the erroneous declarations in contrib modules is more debatable: in principle any change in those scripts should involve an extension version bump, which is a pain. However, since these changes are purely cosmetic and make no functional difference, I think we can get away without doing that.
* Update copyright for 2016Bruce Momjian2016-01-02
| | | | Backpatch certain files through 9.1
* Prevent stack overflow in query-type functions.Noah Misch2015-10-05
| | | | | | The tsquery, ltxtquery and query_int data types have a common ancestor. Having acquired check_stack_depth() calls independently, each was missing at least one call. Back-patch to 9.0 (all supported versions).
* Add selectivity estimation functions for intarray operators.Heikki Linnakangas2015-07-21
| | | | | Uriy Zhuravlev and Alexander Korotkov, reviewed by Jeff Janes, some cleanup by me.
* Move strategy numbers to include/access/stratnum.hAlvaro Herrera2015-05-15
| | | | | | | | | | | | | | | | | | | | For upcoming BRIN opclasses, it's convenient to have strategy numbers defined in a single place. Since there's nothing appropriate, create it. The StrategyNumber typedef now lives there, as well as existing strategy numbers for B-trees (from skey.h) and R-tree-and-friends (from gist.h). skey.h is forced to include stratnum.h because of the StrategyNumber typedef, but gist.h is not; extensions that currently rely on gist.h for rtree strategy numbers might need to add a new A few .c files can stop including skey.h and/or gist.h, which is a nice side benefit. Per discussion: https://www.postgresql.org/message-id/20150514232132.GZ2523@alvh.no-ip.org Authored by Emre Hasegeli and Álvaro. (It's not clear to me why bootscanner.l has any #include lines at all.)
* Centralize definition of integer limits.Andres Freund2015-03-25
| | | | | | | | | | | | | | | | | Several submitted and even committed patches have run into the problem that C89, our baseline, does not provide minimum/maximum values for various integer datatypes. C99's stdint.h does, but we can't rely on it. Several parts of the code defined limits locally, so instead centralize the definitions to c.h. This patch also changes the more obvious usages of literal limit values; there's more places that could be changed, but it's less clear whether it's beneficial to change those. Author: Andrew Gierth Discussion: 87619tc5wc.fsf@news-spur.riddles.org.uk
* Replace insertion sort in contrib/intarray with qsort().Tom Lane2015-03-15
| | | | | | | | | It's all very well to claim that a simplistic sort is fast in easy cases, but O(N^2) in the worst case is not good ... especially if the worst case is as easy to hit as "descending order input". Replace that bit with our standard qsort. Per bug #12866 from Maksym Boguk. Back-patch to all active branches.
* Use FLEXIBLE_ARRAY_MEMBER in a bunch more places.Tom Lane2015-02-20
| | | | | | | | | | | | | | | | Replace some bogus "x[1]" declarations with "x[FLEXIBLE_ARRAY_MEMBER]". Aside from being more self-documenting, this should help prevent bogus warnings from static code analyzers and perhaps compiler misoptimizations. This patch is just a down payment on eliminating the whole problem, but it gets rid of a lot of easy-to-fix cases. Note that the main problem with doing this is that one must no longer rely on computing sizeof(the containing struct), since the result would be compiler-dependent. Instead use offsetof(struct, lastfield). Autoconf also warns against spelling that offsetof(struct, lastfield[0]). Michael Paquier, review and additional fixes by me.
* Eliminate unnecessary NULL checks in picksplit method of intarray.Kevin Grittner2015-02-16
| | | | | | | Where these checks were being done there was no code path which could leave them NULL. Michael Paquier per Coverity
* Fix typos in some error messages thrown by extension scripts when fed to psql.Andres Freund2014-08-25
| | | | | | | | | | Some of the many error messages introduced in 458857cc missed 'FROM unpackaged'. Also e016b724 and 45ffeb7e forgot to quote extension version numbers. Backpatch to 9.1, just like 458857cc which introduced the messages. Do so because the error messages thrown when the wrong command is copy & pasted aren't easy to understand.
* Add file version information to most installed Windows binaries.Noah Misch2014-07-14
| | | | | | | | Prominent binaries already had this metadata. A handful of minor binaries, such as pg_regress.exe, still lack it; efforts to eliminate such exceptions are welcome. Michael Paquier, reviewed by MauMau.
* Adjust blank lines around PG_MODULE_MAGIC defines, for consistencyBruce Momjian2014-07-10
| | | | Report by Robert Haas
* pgindent run for 9.4Bruce Momjian2014-05-06
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-18
| | | | | | | | | | | | | | | | | Because of gcc -Wmissing-prototypes, all functions in dynamically loadable modules must have a separate prototype declaration. This is meant to detect global functions that are not declared in header files, but in cases where the function is called via dfmgr, this is redundant. Besides filling up space with boilerplate, this is a frequent source of compiler warnings in extension modules. We can fix that by creating the function prototype as part of the PG_FUNCTION_INFO_V1 macro, which such modules have to use anyway. That makes the code of modules cleaner, because there is one less place where the entry points have to be listed, and creates an additional check that functions have the right prototype. Remove now redundant prototypes from contrib and other modules.
* Predict integer overflow to avoid buffer overruns.Noah Misch2014-02-17
| | | | | | | | | | | | | | | | | Several functions, mostly type input functions, calculated an allocation size such that the calculation wrapped to a small positive value when arguments implied a sufficiently-large requirement. Writes past the end of the inadvertent small allocation followed shortly thereafter. Coverity identified the path_in() vulnerability; code inspection led to the rest. In passing, add check_stack_depth() to prevent stack overflow in related functions. Back-patch to 8.4 (all supported versions). The non-comment hstore changes touch code that did not exist in 8.4, so that part stops at 9.0. Noah Misch and Heikki Linnakangas, reviewed by Tom Lane. Security: CVE-2014-0064
* Fix whitespace issues found by git diff --check, add gitattributesPeter Eisentraut2013-11-10
| | | | | Set per file type attributes in .gitattributes to fine-tune whitespace checks. With the associated cleanups, the tree is now clean for git
* intarray: return empty zero-dimensional array for an empty arrayBruce Momjian2013-09-07
| | | | | | | | | | Previously a one-dimensional empty array was returned, but its text representation matched a zero-dimensional array, and there is no way to dump/reload a one-dimensional empty array. BACKWARD INCOMPATIBILITY Per report from elein
* Remove unreachable codePeter Eisentraut2012-07-16
| | | | | | | The Solaris Studio compiler warns about these instances, unlike more mainstream compilers such as gcc. But manual inspection showed that the code is clearly not reachable, and we hope no worthy compiler will complain about removing this code.
* Run newly-configured perltidy script on Perl files.Bruce Momjian2012-07-04
| | | | Run on HEAD and 9.2.
* Replace int2/int4 in C code with int16/int32Peter Eisentraut2012-06-25
| | | | | | | | | | The latter was already the dominant use, and it's preferable because in C the convention is that intXX means XX bits. Therefore, allowing mixed use of int2, int4, int8, int16, int32 is obviously confusing. Remove the typedefs for int2 and int4 for now. They don't seem to be widely used outside of the PostgreSQL source tree, and the few uses can probably be cleaned up by the time this ships.
* Add const qualifiers where they are accidentally cast awayPeter Eisentraut2012-02-28
| | | | | This only produces warnings under -Wcast-qual, but it's more correct and consistent in any case.
* Fix longstanding error in contrib/intarray's int[] & int[] operator.Tom Lane2012-02-16
| | | | | | | | | | The array intersection code would give wrong results if the first entry of the correct output array would be "1". (I think only this value could be at risk, since the previous word would always be a lower-bound entry with that fixed value.) Problem spotted by Julien Rouhaud, initial patch by Guillaume Lelarge, cosmetic improvements by me.
* Throw a useful error message if an extension script file is fed to psql.Tom Lane2011-10-12
| | | | | | | | | | | | | | | | We have seen one too many reports of people trying to use 9.1 extension files in the old-fashioned way of sourcing them in psql. Not only does that usually not work (due to failure to substitute for MODULE_PATHNAME and/or @extschema@), but if it did work they'd get a collection of loose objects not an extension. To prevent this, insert an \echo ... \quit line that prints a suitable error message into each extension script file, and teach commands/extension.c to ignore lines starting with \echo. That should not only prevent any adverse consequences of loading a script file the wrong way, but make it crystal clear to users that they need to do it differently now. Tom Lane, following an idea of Andrew Dunstan's. Back-patch into 9.1 ... there is not going to be much value in this if we wait till 9.2.
* Remove many -Wcast-qual warningsPeter Eisentraut2011-09-11
| | | | | | This addresses only those cases that are easy to fix by adding or moving a const qualifier or removing an unnecessary cast. There are many more complicated cases remaining.
* Remove unnecessary #include references, per pgrminclude script.Bruce Momjian2011-09-01
|
* Support "make check" in contribPeter Eisentraut2011-04-25
| | | | | | | | | | | | | | Added a new option --extra-install to pg_regress to arrange installing the respective contrib directory into the temporary installation. This is currently not yet supported for Windows MSVC builds. Updated the .gitignore files for contrib modules to ignore the leftovers of a temp-install check run. Changed the exit status of "make check" in a pgxs build (which still does nothing) to 0 from 1. Added "make check" in contrib to top-level "make check-world".
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-10
|
* One more hack to make contrib upgrades from 9.0 match fresh 9.1 installs.Tom Lane2011-02-18
| | | | | | | | | | | | | | | | | intarray and tsearch2 both reference core support functions in their GIN opclasses, and the signatures of those functions changed for 9.1. We added backwards-compatible pg_proc entries for the functions in order to allow 9.0 dump files to be restored at all, but that hack leaves the opclasses pointing at pg_proc entries different from what they'd point to if the contrib modules were installed fresh in 9.1. To forestall any possibility of future problems, fix the opclasses to match fresh installs via the expedient of direct UPDATEs on pg_amproc in the update-from-unpackaged scripts. (Yech ... but the alternatives are worse, or require far more effort than seems justified right now.) Note: updating pg_amproc is sufficient because there will be no pg_depend entries corresponding to these dependencies, since the referenced functions are all pinned.
* Fix upgrade of contrib/intarray and contrib/unaccent from 9.0.Tom Lane2011-02-17
| | | | | Take care of a couple of discrepancies between what you get from a fresh install and what the first-draft update-from-unpackaged scripts produced.
* Add backwards-compatible declarations of some core GIN support functions.Tom Lane2011-02-16
| | | | | | | | | These are needed to support reloading dumps of 9.0 installations containing contrib/intarray or contrib/tsearch2. Since not only regular dump/reload but binary upgrade would fail, it seems worth the trouble to carry these stubs for awhile. Note that the contrib opclasses referencing these functions will still work fine, since GIN doesn't actually pay any attention to the declared signature of a support function.
* Avoid use of CREATE OR REPLACE FUNCTION in extension installation files.Tom Lane2011-02-13
| | | | | | | | | | | It was never terribly consistent to use OR REPLACE (because of the lack of comparable functionality for data types, operators, etc), and experimentation shows that it's now positively pernicious in the extension world. We really want a failure to occur if there are any conflicts, else it's unclear what the extension-ownership state of the conflicted object ought to be. Most of the time, CREATE EXTENSION will fail anyway because of conflicts on other object types, but an extension defining only functions can succeed, with bad results.
* Convert contrib modules to use the extension facility.Tom Lane2011-02-13
| | | | | | | | | | | This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane
* Prevent buffer overrun while parsing an integer in a "query_int" value.Tom Lane2011-01-27
| | | | | | | | | | | | | | contrib/intarray's gettoken() uses a fixed-size buffer to collect an integer's digits, and did not guard against overrunning the buffer. This is at least a backend crash risk, and in principle might allow arbitrary code execution. The code didn't check for overflow of the integer value either, which while not presenting a crash risk was still bad. Thanks to Apple Inc's security team for reporting this issue and supplying the fix. Security: CVE-2010-4015
* Fix assorted corner-case bugs in contrib/intarray.Tom Lane2011-01-09
| | | | | | | | | | | | | | | | | | | The array containment operators now behave per mathematical expectation for empty arrays (ie, an empty array is contained in anything). Both these operators and the query_int operators now work as expected in GiST and GIN index searches, rather than having corner cases where the index searches gave different answers. Also, fix unexpected failures where the operators would claim that an array contained nulls, when in fact there was no longer any null present (similar to bug #5784). The restriction to not have nulls is still there, as removing it would take a lot of added code complexity and probably slow things down significantly. Also, remove the arbitrary restriction to 1-D arrays; unlike the other restriction, this was buying us nothing performance-wise. Assorted cosmetic improvements and marginal performance improvements, too.
* Update GIN support function definitions for contrib/intarray.Tom Lane2011-01-07
| | | | | The underlying C code still needs work, but this at least gets its current regression test passing again.
* Fix erroneous parsing of tsquery input "... & !(subexpression) | ..."Tom Lane2010-12-19
| | | | | | | | | | | After parsing a parenthesized subexpression, we must pop all pending ANDs and NOTs off the stack, just like the case for a simple operand. Per bug #5793. Also fix clones of this routine in contrib/intarray and contrib/ltree, where input of types query_int and ltxtquery had the same problem. Back-patch to all supported versions.
* Remove useless whitespace at end of linesPeter Eisentraut2010-11-23
|
* Some more gitignore cleanups: cover contrib and PL regression test outputs.Tom Lane2010-09-22
| | | | | Also do some further work in the back branches, where quite a bit wasn't covered by Magnus' original back-patch.
* Convert cvsignore to gitignore, and add .gitignore for build targets.Magnus Hagander2010-09-22
|
* Remove cvs keywords from all files.Magnus Hagander2010-09-20
|
* Remove extra newlines at end and beginning of files, add missing newlinesPeter Eisentraut2010-08-19
| | | | at end of files.
* Fix ginint4_queryextract() to actually do what it was intended to do for anTom Lane2010-03-25
| | | | | | | | | unsatisfiable query, such as indexcol && empty_array. It should return -1 to tell GIN no scan is required; but silly typo disabled the logic for that, resulting in unnecessary "GIN indexes do not support whole-index scans" error. Per bug report from Jeff Trout. Back-patch to 8.3 where the logic was introduced.
* Mark contrib's GiST and GIN opclass support functions as STRICT, for safety.Tom Lane2009-06-11
| | | | | (Note: GiST penalty functions could possibly be non-strict, but none are at present.)
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Revert my patch of 2009-04-04 that removed contrib/intarray's definitions ofTom Lane2009-06-07
| | | | | | | | | | | the <@ and @> operators. These are not in fact equivalent to the built-in anyarray operators of the same names, because they have different behavior for empty arrays, namely they don't think empty arrays are contained in anything. That is mathematically wrong, no doubt, but until we can persuade GIN indexes to implement the mathematical definition we should probably not change this. Another reason for not changing it now is that we can't yet ensure the opclasses will be updated correctly in a dump-and-reload upgrade. Per recent discussions.
* Remove contrib/intarray's definitions of the <@ and @> operators, so that theyTom Lane2009-04-05
| | | | | | | | | | | | don't cause confusion with the built-in anyarray versions of those operators. Adjust the module's index opclasses to support the built-in operators in place of the private ones. The private implementations are still available under their historical names @ and ~, so no functionality is lost. Some quick testing suggests that they offer no real benefit over the core operators, however. Per a complaint from Rusty Conover.
* Adjust the APIs for GIN opclass support functions to allow the extractQuery()Tom Lane2009-03-25
| | | | | | | | | | | | | | method to pass extra data to the consistent() and comparePartial() methods. This is the core infrastructure needed to support the soon-to-appear contrib/btree_gin module. The APIs are still upward compatible with the definitions used in 8.3 and before, although *not* with the previous 8.4devel function definitions. catversion bump for changes in pg_proc entries (although these are just cosmetic, since GIN doesn't actually look at the function signature before calling it...) Teodor Sigaev and Oleg Bartunov
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-20 19:46:56 +0000