postgres/contrib/unaccent/unaccent--unpackaged--1.0.sql

/* contrib/unaccent/unaccent--unpackaged--1.0.sql */

-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION unaccent FROM unpackaged" to load this file. \quit

ALTER EXTENSION unaccent ADD function unaccent(regdictionary,text);
ALTER EXTENSION unaccent ADD function unaccent(text);
ALTER EXTENSION unaccent ADD function unaccent_init(internal);
ALTER EXTENSION unaccent ADD function unaccent_lexize(internal,internal,internal,internal);
ALTER EXTENSION unaccent ADD text search template unaccent;
ALTER EXTENSION unaccent ADD text search dictionary unaccent;

-- These functions are marked as stable in 9.1, were not before:

ALTER FUNCTION unaccent(regdictionary, text) STABLE;
ALTER FUNCTION unaccent(text) STABLE;
Convert contrib modules to use the extension facility. 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 2011-02-13 20:06:41 -05:00			`/* contrib/unaccent/unaccent--unpackaged--1.0.sql */`

Throw a useful error message if an extension script file is fed to psql. 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. 2011-10-12 15:45:03 -04:00			`-- complain if script is sourced in psql, rather than via CREATE EXTENSION`
Fix typos in some error messages thrown by extension scripts when fed to psql. 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. 2014-08-25 18:30:37 +02:00			`\echo Use "CREATE EXTENSION unaccent FROM unpackaged" to load this file. \quit`
Throw a useful error message if an extension script file is fed to psql. 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. 2011-10-12 15:45:03 -04:00
Convert contrib modules to use the extension facility. 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 2011-02-13 20:06:41 -05:00			`ALTER EXTENSION unaccent ADD function unaccent(regdictionary,text);`
			`ALTER EXTENSION unaccent ADD function unaccent(text);`
			`ALTER EXTENSION unaccent ADD function unaccent_init(internal);`
			`ALTER EXTENSION unaccent ADD function unaccent_lexize(internal,internal,internal,internal);`
			`ALTER EXTENSION unaccent ADD text search template unaccent;`
			`ALTER EXTENSION unaccent ADD text search dictionary unaccent;`
Fix upgrade of contrib/intarray and contrib/unaccent from 9.0. 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. 2011-02-17 17:45:09 -05:00
unaccent: Revert patch 9299f6179838cef8aa1123f6fb76f0d3d6f2decc The reverted patch to change functions from strict to immutable was incorrect and needs additional research. 2013-11-18 15:54:34 -05:00			`-- These functions are marked as stable in 9.1, were not before:`
Fix upgrade of contrib/intarray and contrib/unaccent from 9.0. 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. 2011-02-17 17:45:09 -05:00
unaccent: Revert patch 9299f6179838cef8aa1123f6fb76f0d3d6f2decc The reverted patch to change functions from strict to immutable was incorrect and needs additional research. 2013-11-18 15:54:34 -05:00			`ALTER FUNCTION unaccent(regdictionary, text) STABLE;`
			`ALTER FUNCTION unaccent(text) STABLE;`