summaryrefslogtreecommitdiff
path: root/contrib/uuid-ossp
Commit message (Collapse)AuthorAgeFilesLines
* Remove support for upgrading extensions from "unpackaged" state.Tom Lane2020-02-192-16/+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
* Update copyrights for 2020Bruce Momjian2020-01-011-1/+1
| | | | Backpatch-through: update all files in master, backpatch legal files through 9.4
* Split all OBJS style lines in makefiles into one-line-per-entry style.Andres Freund2019-11-051-1/+4
| | | | | | | | | | | | | | | 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
* Update copyright for 2019Bruce Momjian2019-01-021-1/+1
| | | | Backpatch-through: certain files through 9.4
* Update copyright for 2018Bruce Momjian2018-01-021-1/+1
| | | | Backpatch-through: certain files through 9.3
* Add some const decorations to prototypesPeter Eisentraut2017-11-101-1/+1
| | | | Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
* Replace most usages of ntoh[ls] and hton[sl] with pg_bswap.h.Andres Freund2017-10-011-10/+7
| | | | | | | | | | | | | | | | | All postgres internal usages are replaced, it's just libpq example usages that haven't been converted. External users of libpq can't generally rely on including postgres internal headers. Note that this includes replacing open-coded byte swapping of 64bit integers (using two 32 bit swaps) with a single 64bit swap. Where it looked applicable, I have removed netinet/in.h and arpa/inet.h usage, which previously provided the relevant functionality. It's perfectly possible that I missed other reasons for including those, the buildfarm will tell. Author: Andres Freund Discussion: https://postgr.es/m/20170927172019.gheidqy6xvlxb325@alap3.anarazel.de
* Phase 2 of pgindent updates.Tom Lane2017-06-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. 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
* Initial pgindent run with pg_bsd_indent version 2.0.Tom Lane2017-06-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Use wrappers of PG_DETOAST_DATUM_PACKED() more.Noah Misch2017-03-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This makes almost all core code follow the policy introduced in the previous commit. Specific decisions: - Text search support functions with char* and length arguments, such as prsstart and lexize, may receive unaligned strings. I doubt maintainers of non-core text search code will notice. - Use plain VARDATA() on values detoasted or synthesized earlier in the same function. Use VARDATA_ANY() on varlenas sourced outside the function, even if they happen to always have four-byte headers. As an exception, retain the universal practice of using VARDATA() on return values of SendFunctionCall(). - Retain PG_GETARG_BYTEA_P() in pageinspect. (Page images are too large for a one-byte header, so this misses no optimization.) Sites that do not call get_page_from_raw() typically need the four-byte alignment. - For now, do not change btree_gist. Its use of four-byte headers in memory is partly entangled with storage of 4-byte headers inside GBT_VARKEY, on disk. - For now, do not change gtrgm_consistent() or gtrgm_distance(). They incorporate the varlena header into a cache, and there are multiple credible implementation strategies to consider.
* Update copyright via script for 2017Bruce Momjian2017-01-031-1/+1
|
* Give a useful error message if uuid-ossp is built without preconfiguration.Tom Lane2016-12-221-5/+5
| | | | | | | | | | | | | | | | | | | | Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without having told configure you meant to; you could just cd into that directory and "make". That no longer works because the code depends on configure to have done header and library probes, but the ensuing error messages are not so easy to interpret if you're not an old C hand. We've gotten a couple of complaints recently from people trying to do this the low-tech way, so add an explicit #error directing the user to use --with-uuid. (In principle we might want to do something similar in the other optionally-built contrib modules; but I don't think any of the others have ever worked without preconfiguration, so there are no bad habits to break people of.) Back-patch to 9.4 where the previous commit came in. Report: https://postgr.es/m/CAHeEsBf42AWTnk=1qJvFv+mYgRFm07Knsfuc86Ono8nRjf3tvQ@mail.gmail.com Report: https://postgr.es/m/CAKYdkBrUaZX+F6KpmzoHqMtiUqCtAW_w6Dgvr6F0WTiopuGxow@mail.gmail.com
* In contrib/uuid-ossp, #include headers needed for ntohl() and ntohs().Tom Lane2016-12-171-0/+4
| | | | | | | | | | | | Oversight in commit b8cc8f947. I just noticed this causes compiler warnings on FreeBSD, and it really ought to cause warnings elsewhere too: all references I can find say that <arpa/inet.h> is required for these. We have a lot of code elsewhere that thinks that both <netinet/in.h> and <arpa/inet.h> should be included for these functions, so do it that way here too, even though <arpa/inet.h> ought to be sufficient according to the references I consulted. Back-patch to 9.4 where the previous commit landed.
* Update uuid-ossp extension for parallel query.Robert Haas2016-06-144-13/+28
| | | | | | All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson
* Update copyright for 2016Bruce Momjian2016-01-021-1/+1
| | | | Backpatch certain files through 9.1
* Update copyright for 2015Bruce Momjian2015-01-061-1/+1
| | | | Backpatch certain files through 9.0
* 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.
* Adjust blank lines around PG_MODULE_MAGIC defines, for consistencyBruce Momjian2014-07-101-2/+0
| | | | Report by Robert Haas
* When using the OSSP UUID library, cache its uuid_t state object.Tom Lane2014-05-291-31/+45
| | | | | | | | | | | | | | | | The original coding in contrib/uuid-ossp created and destroyed a uuid_t object (or, in some cases, even two of them) each time it was called. This is not the intended usage: you're supposed to keep the uuid_t object around so that the library can cache its state across uses. (Other UUID libraries seem to keep equivalent state behind-the-scenes in static variables, but OSSP chose differently.) Aside from being quite inefficient, creating a new uuid_t loses knowledge of the previously generated UUID, which in theory could result in duplicate V1-style UUIDs being created on sufficiently fast machines. On at least some platforms, creating a new uuid_t also draws some entropy from /dev/urandom, leaving less for the rest of the system. This seems sufficiently unpleasant to justify back-patching this change.
* Fix uuid-ossp regression tests based on buildfarm feedback.Tom Lane2014-05-282-22/+56
| | | | | | | | | | | | | | | | | | | The previous version of these tests expected uuid_generate_v1() to always emit MAC addresses with the local-admin and multicast address bits zero. However, several of the buildfarm critters are reporting values with the local-admin bit set. (Perhaps they're running inside VMs or jails.) And a couple are reporting values with the multicast bit set, probably meaning that the UUID library couldn't read the system MAC address. Also, it emerges that if OSSP UUID can't read the system MAC address, it falls back to V1MC behavior wherein the whole node field gets randomized each time, breaking the test that expected the node field to remain stable in V1 output. (It looks like e2fs doesn't behave that way, though.) It's not entirely clear why we can't get a system MAC address, since the buildfarm scripts would not work without internet access. Nonetheless, the regression tests had better cope with the case, so adjust the tests to expect these behaviors.
* Improve regression tests for uuid-ossp.Tom Lane2014-05-282-21/+88
| | | | | | | | | On reflection, the timestamp-advances test might fail if we're unlucky enough for the time_mid field to change between two calls, since uuid_cmp is just bytewise comparison and the field ordering has more significant fields later. Build some field extraction functions so we can do a more honest test of that. Also check that the version and reserved fields contain what they should.
* Fix stack clobber in new uuid-ossp code.Tom Lane2014-05-281-1/+4
| | | | | | The V5 (SHA1 hashing) code wrote 20 bytes into a 16-byte local variable. This had accidentally failed to fail in my testing and Matteo's, but buildfarm results exposed the problem.
* Support BSD and e2fsprogs UUID libraries alongside OSSP UUID library.Tom Lane2014-05-275-63/+473
| | | | | | | | | | | | | | | | | | | Allow the contrib/uuid-ossp extension to be built atop any one of these three popular UUID libraries. (The extension's name is now arguably a misnomer, but we'll keep it the same so as not to cause unnecessary compatibility issues for users.) We would not normally consider a change like this post-beta1, but the issue has been forced by our upgrade to autoconf 2.69, whose more rigorous header checks are causing OSSP's header files to be rejected on some platforms. It's been foreseen for some time that we'd have to move away from depending on OSSP UUID due to lack of upstream maintenance, so this is a down payment on that problem. While at it, add some simple regression tests, in hopes of catching any major incompatibilities between the three implementations. Matteo Beccati, with some further hacking by me
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-181-13/+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.
* Update copyright for 2014Bruce Momjian2014-01-071-1/+1
| | | | | Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
* Fix quoting in help messages in uuid-ossp extension scripts.Tom Lane2013-11-222-2/+2
| | | | | | The command we're telling people to type needs to include double-quoting around the unfortunately-chosen extension name. Twiddle the textual quoting so that it looks somewhat sane. Per gripe from roadrunner6.
* Update copyrights for 2013Bruce Momjian2013-01-011-1/+1
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Update copyright notices for year 2012.Bruce Momjian2012-01-011-1/+1
|
* 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.
* Avoid use of CREATE OR REPLACE FUNCTION in extension installation files.Tom Lane2011-02-131-10/+10
| | | | | | | | | | | 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-136-23/+21
| | | | | | | | | | | 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
* Stamp copyrights for year 2011.Bruce Momjian2011-01-011-1/+1
|
* Add .gitignore for contrib/uuid-ossp.Itagaki Takahiro2010-10-261-0/+1
|
* Remove cvs keywords from all files.Magnus Hagander2010-09-204-4/+4
|
* Update copyright for the year 2010.Bruce Momjian2010-01-021-2/+2
|
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-5/+5
| | | | provided by Andrew.
* Add comma so this copyright notice is picked up in 2010.Bruce Momjian2009-01-011-2/+2
|
* Fix a couple of missed copyright dates.Tom Lane2009-01-011-2/+2
|
* Simplify and standardize conversions between TEXT datums and ordinary CTom Lane2008-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
* Fix some missed copyright updates.Tom Lane2008-01-011-2/+2
|
* Add missing return code checks in the uuid-ossp contrib module, per bug #3841.Alvaro Herrera2007-12-311-13/+53
|
* Re-run pgindent with updated list of typedefs. (Updated README shouldBruce Momjian2007-11-151-2/+2
| | | | avoid this problem in the future.)
* pgindent run for 8.3.Bruce Momjian2007-11-151-23/+23
|
* Add CVS version labels to all install/uninstall scripts.Bruce Momjian2007-11-132-0/+4
|
* Adjust script to be consistent (thanks Tom for the fix).Bruce Momjian2007-11-131-2/+0
|
* Undo damage from yesterday's script "cleanup".Tom Lane2007-11-131-22/+23
|
* I find that an out-of-the-box installation of OSSP uuid 1.6.0 installsTom Lane2007-11-131-2/+2
| | | | | | itself as libuuid, not libossp-uuid which was the only case expected by our build support. Install a configure test to determine which name to use (and to check that the library is present at all).
* Make /contrib install/uninstall script consistent:Bruce Momjian2007-11-112-15/+52
| | | | | | | | | | | | remove transactions use create or replace function make formatting consistent set search patch on first line Add documentation on modifying *.sql to set the search patch, and mention that major upgrades should still run the installation scripts. Some of these issues were spotted by Tom today.
View Lorry Controller Status