summaryrefslogtreecommitdiff
path: root/contrib/lo
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
* meson: Add windows resource filesAndres Freund2022-10-051-0/+6
| | | | | | | | | | | | | 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/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 bogus CALLED_AS_TRIGGER() defenses.Tom Lane2020-04-031-2/+1
| | | | | | | | | | | | | | | | | | | | | contrib/lo's lo_manage() thought it could use trigdata->tg_trigger->tgname in its error message about not being called as a trigger. That naturally led to a core dump. unique_key_recheck() figured it could Assert that fcinfo->context is a TriggerData node in advance of having checked that it's being called as a trigger. That's harmless in production builds, and perhaps not that easy to reach in any case, but it's logically wrong. The first of these per bug #16340 from William Crowell; the second from manual inspection of other CALLED_AS_TRIGGER call sites. Back-patch the lo.c change to all supported branches, the other to v10 where the thinko crept in. Discussion: https://postgr.es/m/16340-591c7449dc7c8c47@postgresql.org
* Add tg_updatedcols to TriggerDataPeter Eisentraut2020-03-093-1/+15
| | | | | | | | | | This allows a trigger function to determine for an UPDATE trigger which columns were actually updated. This allows some optimizations in generic trigger functions such as lo_manage and tsvector_update_trigger. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/flat/11c5f156-67a9-0fb5-8200-2a8018eb2e0c@2ndquadrant.com
* Remove support for upgrading extensions from "unpackaged" state.Tom Lane2020-02-192-9/+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
* lo: Add test suitePeter Eisentraut2017-09-144-0/+73
| | | | Reviewed-by: David Steele <david@pgmasters.net>
* 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
* Move atooid() definition to a central placePeter Eisentraut2017-03-011-2/+0
|
* Generate fmgr prototypes automaticallyPeter Eisentraut2017-01-171-1/+1
| | | | | | | | | | | | Gen_fmgrtab.pl creates a new file fmgrprotos.h, which contains prototypes for all functions registered in pg_proc.h. This avoids having to manually maintain these prototypes across a random variety of header files. It also automatically enforces a correct function signature, and since there are warnings about missing prototypes, it will detect functions that are defined but not registered in pg_proc.h (or otherwise used). Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
* Rename C symbols for backend lo_ functionsPeter Eisentraut2017-01-171-2/+2
| | | | | | | Rename the C symbols for lo_* to be_lo_*, so they don't conflict with libpq prototypes. Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
* Update lo extension for parallel query.Robert Haas2016-06-074-4/+10
| | | | | | The lo_oid function provided by this extension is PARALLEL SAFE. Andreas Karlsson
* 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-0/+1
| | | | | | | | 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-1/+0
| | | | Report by Robert Haas
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-181-4/+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.
* Defend against bad trigger definitions in contrib/lo's lo_manage() trigger.Tom Lane2013-11-231-2/+12
| | | | | | | | | | | This function formerly crashed if called as a statement-level trigger, or if a column-name argument wasn't given. In passing, add the trigger name to all error messages from the function. (None of them are expected cases, so this shouldn't pose any compatibility risk.) Marc Cousin, reviewed by Sawada Masahiko
* 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
|
* Move Trigger and TriggerDesc structs out of rel.h into a new reltrigger.hAlvaro Herrera2011-07-041-5/+2
| | | | | This lets us stop including rel.h into execnodes.h, which is a widely used header.
* Avoid use of CREATE OR REPLACE FUNCTION in extension installation files.Tom Lane2011-02-131-2/+2
| | | | | | | | | | | 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-24/+14
| | | | | | | | | | | 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
* 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-205-5/+5
|
* Additional fixes for large object access control.Itagaki Takahiro2009-12-141-3/+3
| | | | | | Use pg_largeobject_metadata.oid instead of pg_largeobject.loid to enumerate existing large objects in pg_dump, pg_restore, and contrib modules.
* Add CVS version labels to all install/uninstall scripts.Bruce Momjian2007-11-133-0/+6
|
* Make /contrib install/uninstall script consistent:Bruce Momjian2007-11-113-11/+8
| | | | | | | | | | | | 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.
* Remove references to READMEs from /contrib Makefiles.Bruce Momjian2007-11-101-2/+1
|
* Move most /contrib README files into SGML. Some still need conversionBruce Momjian2007-11-101-88/+0
| | | | or will never be converted.
* Fix PGXS conventions so that extensions can be built against PostgresTom Lane2007-06-261-2/+3
| | | | | | installations whose pg_config program does not appear first in the PATH. Per gripe from Eddie Stanley and subsequent discussions with Fabien Coelho and others.
* Rename the uninstall scripts for contrib/lo and contrib/tsearch2 toTom Lane2006-09-112-2/+2
| | | | | | | match the convention that foo's uninstall script is uninstall_foo.sql. Also, stop installing lo_test.sql, which really ought to be made into a regression test anyway (though it's unclear how to avoid a dependency on the current OID counter...)
* Alphabetically order reference to include files, "G" - "M".Bruce Momjian2006-07-111-5/+5
|
* Magic blocks don't do us any good unless we use 'em ... so install oneTom Lane2006-05-301-1/+2
| | | | in every shared library.
* PGXS should be set with := not =, as specified in the documentation,Tom Lane2005-09-271-2/+2
| | | | to avoid useless multiple executions of pg_config.
* Cleanup the contrib/lo module: there is no need anymore to implementTom Lane2005-06-235-202/+86
| | | | | | | | a physically separate type. Defining 'lo' as a domain over OID works just fine and is more efficient. Improve documentation and fix up the test script. (Would like to turn test script into a proper regression test, but right now its output is not constant because of numeric OIDs; plus it makes Unix-specific assumptions about files it can import.)
* Make sure contrib C functions are marked strict where needed.Tom Lane2005-01-291-7/+7
| | | | Kris Jurka
* > Please find enclose a submission to fix these problems.Bruce Momjian2004-08-201-5/+9
| | | | | | | | | | | | | | | | | | | | | | > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO
* make sure the $Id tags are converted to $PostgreSQL as well ...PostgreSQL Daemon2003-11-291-1/+1
|
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-292-2/+2
|
* Error message editing in contrib (mostly by Joe Conway --- thanks Joe!)Tom Lane2003-07-241-5/+11
|
* Backend support for autocommit removed, per recent discussions. TheTom Lane2003-05-142-5/+1
| | | | | | only remnant of this failed experiment is that the server will take SET AUTOCOMMIT TO ON. Still TODO: provide some client-side autocommit logic in libpq.
* Add casts between lo and oid.Hiroshi Inoue2002-12-311-6/+8
|
* Update /contrib for "autocommit TO 'on'".Bruce Momjian2002-10-183-55/+78
| | | | | | | | | | Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
* Add a bunch of pseudo-types to replace the behavior formerly associatedTom Lane2002-08-222-15/+9
| | | | | | with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
* The attached patch changes most of the usages of sprintf() toBruce Momjian2002-08-151-2/+2
| | | | | | | | | snprintf() in contrib/. I didn't touch the places where pointer arithmatic was being used, or other areas where the fix wasn't trivial. I would think that few, if any, of the usages of sprintf() were actually exploitable, but it's probably better to be paranoid... Neil Conway
* Fix a lo_manage()'s bug.Hiroshi Inoue2001-12-071-2/+2
|
* Another pgindent run. Fixes enum indenting, and improves #endifBruce Momjian2001-10-281-4/+4
| | | | spacing. Also adds space for one-line comments.
* pgindent run on all C files. Java run to follow. initdb/regressionBruce Momjian2001-10-251-5/+4
| | | | tests pass.
View Lorry Controller Status