summaryrefslogtreecommitdiff
path: root/contrib/btree_gin
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright for 2023Bruce Momjian2023-01-021-1/+1
| | | | Backpatch-through: 11
* Add copyright notices to meson filesAndrew Dunstan2022-12-201-0/+2
| | | | Discussion: https://postgr.es/m/222b43a5-2fb3-2c1b-9cd0-375d376c8246@dunslane.net
* Produce more-optimal plans for bitmap scans on boolean columns.Tom Lane2022-11-082-1/+15
| | | | | | | | | | | | | | | | | | | | | | | The planner simplifies boolean comparisons such as "x = true" and "x = false" down to "x" and "NOT x" respectively, to have a canonical form to ease comparisons. However, if we want to use an index on x, the index AM APIs require us to reconstitute the comparison-operator form of the indexqual. While that works, in bitmap indexscans the canonical form of the qual was emitted as a "filter" condition although it really only needs to be a "recheck" condition, because create_bitmap_scan_plan didn't recognize the equivalence of that form with the generated indexqual. booleq() is pretty cheap so that likely doesn't make very much difference, but it's unsightly so let's clean it up. To fix, add a case to predicate_implied_by() to recognize the equivalence of such clauses. This is a relatively low-cost place to add a check, and perhaps it will have additional use cases in future. Richard Guo and Tom Lane, per discussion of bug #17618 from Sindy Senorita. Discussion: https://postgr.es/m/17618-7a2240bfaa7e84ae@postgresql.org
* meson: Add windows resource filesAndres Freund2022-10-051-1/+11
| | | | | | | | | | | | | The generated resource files aren't exactly the same ones as the old buildsystems generate. Previously "InternalName" and "OriginalFileName" were mostly wrong / not set (despite being required), but that was hard to fix in at least the make build. Additionally, the meson build falls back to a "auto-generated" description when not set, and doesn't set it in a few cases - unlikely that anybody looks at these descriptions in detail. Author: Andres Freund <andres@anarazel.de> Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
* meson: Add initial version of meson based build systemAndres Freund2022-09-211-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Autoconf is showing its age, fewer and fewer contributors know how to wrangle it. Recursive make has a lot of hard to resolve dependency issues and slow incremental rebuilds. Our home-grown MSVC build system is hard to maintain for developers not using Windows and runs tests serially. While these and other issues could individually be addressed with incremental improvements, together they seem best addressed by moving to a more modern build system. After evaluating different build system choices, we chose to use meson, to a good degree based on the adoption by other open source projects. We decided that it's more realistic to commit a relatively early version of the new build system and mature it in tree. This commit adds an initial version of a meson based build system. It supports building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD, Solaris and Windows (however only gcc is supported on aix, solaris). For Windows/MSVC postgres can now be built with ninja (faster, particularly for incremental builds) and msbuild (supporting the visual studio GUI, but building slower). Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM bitcode generation, documentation adjustments) are done in subsequent commits requiring further review. Other aspects (e.g. not installing test-only extensions) are not yet addressed. When building on Windows with msbuild, builds are slower when using a visual studio version older than 2019, because those versions do not support MultiToolTask, required by meson for intra-target parallelism. The plan is to remove the MSVC specific build system in src/tools/msvc soon after reaching feature parity. However, we're not planning to remove the autoconf/make build system in the near future. Likely we're going to keep at least the parts required for PGXS to keep working around until all supported versions build with meson. Some initial help for postgres developers is at https://wiki.postgresql.org/wiki/Meson With contributions from Thomas Munro, John Naylor, Stone Tickle and others. Author: Andres Freund <andres@anarazel.de> Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Author: Peter Eisentraut <peter@eisentraut.org> Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
* Fix planner to consider matches to boolean columns in extension indexes.Tom Lane2022-09-021-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The planner has to special-case indexes on boolean columns, because what we need for an indexscan on such a column is a qual of the shape of "boolvar = pseudoconstant". For plain bool constants, previous simplification will have reduced this to "boolvar" or "NOT boolvar", and we have to reverse that if we want to make an indexqual. There is existing code to do so, but it only fires when the index's opfamily is BOOL_BTREE_FAM_OID or BOOL_HASH_FAM_OID. Thus extension AMs, or extension opclasses such as contrib/btree_gin, are out in the cold. The reason for hard-wiring the set of relevant opfamilies was mostly to avoid a catalog lookup in a hot code path. We can improve matters while not taking much of a performance hit by relying on the hard-wired set when the opfamily OID is visibly built-in, and only checking the catalogs when dealing with an extension opfamily. While here, rename IsBooleanOpfamily to IsBuiltinBooleanOpfamily to remind future users of that macro of its limitations. At some point we might want to make indxpath.c's improved version of the test globally accessible, but it's not presently needed elsewhere. Zongliang Quan and Tom Lane Discussion: https://postgr.es/m/f293b91d-1d46-d386-b6bb-4b06ff5c667b@yeah.net
* Fix failure of btree_gin indexscans with "char" type and </<= operators.Tom Lane2021-08-102-3/+10
| | | | | | | | | | | | | | As a result of confusion about whether the "char" type is signed or unsigned, scans for index searches like "col < 'x'" or "col <= 'x'" would start at the middle of the index not the left end, thus missing many or all of the entries they should find. Fortunately, this is not a symptom of index corruption. It's only the search logic that is broken, and we can fix it without unpleasant side-effects. Per report from Jason Kim. This has been wrong since btree_gin's beginning, so back-patch to all supported branches. Discussion: https://postgr.es/m/20210810001649.htnltbh7c63re42p@jasonk.me
* Remove support for upgrading extensions from "unpackaged" state.Tom Lane2020-02-192-120/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Andres Freund pointed out that allowing non-superusers to run "CREATE EXTENSION ... FROM unpackaged" has security risks, since the unpackaged-to-1.0 scripts don't try to verify that the existing objects they're modifying are what they expect. Just attaching such objects to an extension doesn't seem too dangerous, but some of them do more than that. We could have resolved this, perhaps, by still requiring superuser privilege to use the FROM option. However, it's fair to ask just what we're accomplishing by continuing to lug the unpackaged-to-1.0 scripts forward. None of them have received any real testing since 9.1 days, so they may not even work anymore (even assuming that one could still load the previous "loose" object definitions into a v13 database). And an installation that's trying to go from pre-9.1 to v13 or later in one jump is going to have worse compatibility problems than whether there's a trivial way to convert their contrib modules into extension style. Hence, let's just drop both those scripts and the core-code support for "CREATE EXTENSION ... FROM". Discussion: https://postgr.es/m/20200213233015.r6rnubcvl4egdh5r@alap3.anarazel.de
* Mark some contrib modules as "trusted".Tom Lane2020-02-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows these modules to be installed into a database without superuser privileges (assuming that the DBA or sysadmin has installed the module's files in the expected place). You only need CREATE privilege on the current database, which by default would be available to the database owner. The following modules are marked trusted: btree_gin btree_gist citext cube dict_int earthdistance fuzzystrmatch hstore hstore_plperl intarray isn jsonb_plperl lo ltree pg_trgm pgcrypto seg tablefunc tcn tsm_system_rows tsm_system_time unaccent uuid-ossp In the future we might mark some more modules trusted, but there seems to be no debate about these, and on the whole it seems wise to be conservative with use of this feature to start out with. Discussion: https://postgr.es/m/32315.1580326876@sss.pgh.pa.us
* Clean up newlines following left parenthesesAlvaro Herrera2020-01-301-4/+2
| | | | | | | | | | | | We used to strategically place newlines after some function call left parentheses to make pgindent move the argument list a few chars to the left, so that the whole line would fit under 80 chars. However, pgindent no longer does that, so the newlines just made the code vertically longer for no reason. Remove those newlines, and reflow some of those lines for some extra naturality. Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql
* Split all OBJS style lines in makefiles into one-line-per-entry style.Andres Freund2019-11-051-1/+3
| | | | | | | | | | | | | | | When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
* Make the order of the header file includes consistent in contrib modules.Amit Kapila2019-10-241-1/+1
| | | | | | | | | | | | | | 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
* Provide separate header file for built-in float typesTomas Vondra2018-07-291-0/+1
| | | | | | | | | | | | | | | | | | Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
* Clean up warnings from -Wimplicit-fallthrough.Tom Lane2018-05-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Recent gcc can warn about switch-case fall throughs that are not explicitly labeled as intentional. This seems like a good thing, so clean up the warnings exposed thereby by labeling all such cases with comments that gcc will recognize. In files that already had one or more suitable comments, I generally matched the existing style of those. Otherwise I went with /* FALLTHROUGH */, which is one of the spellings approved at the more-restrictive-than-default level -Wimplicit-fallthrough=4. (At the default level you can also spell it /* FALL ?THRU */, and it's not picky about case. What you can't do is include additional text in the same comment, so some existing comments containing versions of this aren't good enough.) Testing with gcc 8.0.1 (Fedora 28's current version), I found that I also had to put explicit "break"s after elog(ERROR) or ereport(ERROR); apparently, for this purpose gcc doesn't recognize that those don't return. That seems like possibly a gcc bug, but it's fine because in most places we did that anyway; so this amounts to a visit from the style police. Discussion: https://postgr.es/m/15083.1525207729@sss.pgh.pa.us
* Post-feature-freeze pgindent run.Tom Lane2018-04-261-3/+8
| | | | Discussion: https://postgr.es/m/15719.1523984266@sss.pgh.pa.us
* Add support of bool, bpchar, name and uuid to btree_ginTeodor Sigaev2018-04-0512-4/+688
| | | | | | | | | | | Mostly for completeness, but I believe there are cases to use that in multicolumn GIN indexes. Bump btree_gin module version Author: Matheus Oliveira Reviewed by: Tomas Vondra Discussion: https://www.postgresql.org/message-id/flat/CAJghg4LMJf6Z13fnZD-MBNiGxzd0cA2=F3TDjNkX3eQH58hktQ@mail.gmail.com
* Phase 3 of pgindent updates.Tom Lane2017-06-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Post-PG 10 beta1 pgindent runBruce Momjian2017-05-171-16/+16
| | | | perltidy run not included.
* Add btree_gin support for enum typesAndrew Dunstan2017-03-216-11/+199
| | | | | | Reviewed by Tom Lane and Anastasia Lubennikova Discussion: http://postgr.es/m/56EA8A71.8060107@dunslane.net
* Add support for EUI-64 MAC addresses as macaddr8Stephen Frost2017-03-156-3/+121
| | | | | | | | | | | | | | | | | | | | | This adds in support for EUI-64 MAC addresses by adding a new data type called 'macaddr8' (using our usual convention of indicating the number of bytes stored). This was largely a copy-and-paste from the macaddr data type, with appropriate adjustments for having 8 bytes instead of 6 and adding support for converting a provided EUI-48 (6 byte format) to the EUI-64 format. Conversion from EUI-48 to EUI-64 inserts FFFE as the 4th and 5th bytes but does not perform the IPv6 modified EUI-64 action of flipping the 7th bit, but we add a function to perform that specific action for the user as it may be commonly done by users who wish to calculate their IPv6 address based on their network prefix and 48-bit MAC address. Author: Haribabu Kommi, with a good bit of rework of macaddr8_in by me. Reviewed by: Vitaly Burovoy, Kuntal Ghosh Discussion: https://postgr.es/m/CAJrrPGcUi8ZH+KkK+=TctNQ+EfkeCEHtMU_yo1mvX8hsk_ghNQ@mail.gmail.com
* Test all contrib-created operator classes with amvalidate.Tom Lane2016-11-292-0/+13
| | | | | | | | | | | | | I'd supposed that people would do this manually when creating new operator classes, but the folly of that was exposed today. The tests seem fast enough that we can just apply them during the normal regression tests. contrib/isn fails the checks for lack of complete sets of cross-type operators. That's a nice-to-have policy rather than a functional requirement, so leave it as-is, but insert ORDER BY in the query to ensure consistent cross-platform output. Discussion: https://postgr.es/m/7076.1480446837@sss.pgh.pa.us
* Make contrib regression tests safe for Danish locale.Tom Lane2016-07-216-12/+12
| | | | | | | | | | In btree_gin and citext, avoid some not-particularly-interesting dependencies on the sorting of 'aa'. In tsearch2, use COLLATE "C" to remove an uninteresting dependency on locale sort order (and thereby allow removal of a variant expected-file). Also, in citext, avoid assuming that lower('I') = 'i'. This isn't relevant to Danish but it does fail in Turkish.
* Use correct symbol for minimum int64 valuePeter Eisentraut2016-07-171-8/+2
| | | | | | | The old code used SEQ_MINVALUE to get the smallest int64 value. This was done as a convenience to avoid having to deal with INT64_IS_BUSTED, but that is obsolete now. Also, it is incorrect because the smallest int64 value is actually SEQ_MINVALUE-1. Fix by using PG_INT64_MIN.
* pgindent run for 9.5Bruce Momjian2015-05-231-8/+27
|
* Move strategy numbers to include/access/stratnum.hAlvaro Herrera2015-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | 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.)
* btree_gin: properly call DirectFunctionCall1()Bruce Momjian2015-03-311-4/+1
| | | | | | | Previously we called DirectFunctionCall3() with dummy arguments. Fixed version of previous patch. Report by Jon Nelson
* Revert commit 843cd0bfe6246d94d9b34a7f36bbb76fdba87b74Bruce Momjian2015-03-241-3/+12
| | | | Report by Tom Lane
* btree_gin: properly call DirectFunctionCall1()Bruce Momjian2015-03-241-12/+3
| | | | | | Previously we called DirectFunctionCall3() with dummy arguments. Patch by Jon Nelson
* Turn much of the btree_gin macros into real functions.Heikki Linnakangas2014-12-221-202/+173
| | | | | This makes the functions much nicer to read and edit, and also makes debugging easier.
* Fix typos in some error messages thrown by extension scripts when fed to psql.Andres Freund2014-08-251-1/+1
| | | | | | | | | | 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-141-1/+2
| | | | | | | | 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.
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-181-5/+0
| | | | | | | | | | | | | | | | | 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.
* Throw a useful error message if an extension script file is fed to psql.Tom Lane2011-10-122-0/+6
| | | | | | | | | | | | | | | | 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 unnecessary #include references, per pgrminclude script.Bruce Momjian2011-09-011-1/+0
|
* Support "make check" in contribPeter Eisentraut2011-04-251-0/+2
| | | | | | | | | | | | | | 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".
* De-kludge contrib/btree_gin for collations.Tom Lane2011-04-221-2/+1
| | | | | | | | | Using DEFAULT_COLLATION_OID in the comparePartial functions was not only a lame hack, but outright wrong, because the compare functions for collation-aware types were already responding to the declared index collation. So comparePartial would have the wrong expectation about the index's sort order, possibly leading to missing matches for prefix searches.
* Pass collations to functions in FunctionCallInfoData, not FmgrInfo.Tom Lane2011-04-121-1/+1
| | | | | | | | | | | Since collation is effectively an argument, not a property of the function, FmgrInfo is really the wrong place for it; and this becomes critical in cases where a cached FmgrInfo is used for varying purposes that might need different collation settings. Fix by passing it in FunctionCallInfoData instead. In particular this allows a clean fix for bug #5970 (record_cmp not working). This requires touching a bit more code than the original method, but nobody ever thought that collations would not be an invasive patch...
* Avoid use of CREATE OR REPLACE FUNCTION in extension installation files.Tom Lane2011-02-131-68/+68
| | | | | | | | | | | 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-138-113/+127
| | | | | | | | | | | 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
* Per-column collation supportPeter Eisentraut2011-02-081-1/+3
| | | | | | | | This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
* Improve comment.Tom Lane2011-01-091-4/+5
|
* Remove useless whitespace at end of linesPeter Eisentraut2010-11-2319-19/+19
|
* Some more gitignore cleanups: cover contrib and PL regression test outputs.Tom Lane2010-09-221-0/+2
| | | | | 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-221-0/+1
|
* Remove cvs keywords from all files.Magnus Hagander2010-09-204-4/+4
|
* Remove all the special-case code for INT64_IS_BUSTED, per decision thatTom Lane2010-01-071-5/+3
| | | | | | | | we're not going to support that anymore. I did keep the 64-bit-CRC-with-32-bit-arithmetic code, since it has a performance excuse to live. It's a bit moot since that's all ifdef'd out, of course.
* Ooops, missed that a couple of contrib modules have calls to byteacmp.Tom Lane2009-08-043-1/+6
| | | | | Add bytea.h inclusions as needed. Some of the contrib regression tests need to be de-hexified, too. Per buildfarm.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-31/+53
| | | | provided by Andrew.
* Add btree_gin contrib module.Tom Lane2009-03-2552-0/+2713
Teodor Sigaev and Oleg Bartunov
View Lorry Controller Status