postgresql/contrib/test_parser/test_parser--1.0.sql

/* contrib/test_parser/test_parser--1.0.sql */

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

CREATE FUNCTION testprs_start(internal, int4)
RETURNS internal
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;

CREATE FUNCTION testprs_getlexeme(internal, internal, internal)
RETURNS internal
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;

CREATE FUNCTION testprs_end(internal)
RETURNS void
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;

CREATE FUNCTION testprs_lextype(internal)
RETURNS internal
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT;

CREATE TEXT SEARCH PARSER testparser (
    START    = testprs_start,
    GETTOKEN = testprs_getlexeme,
    END      = testprs_end,
    HEADLINE = pg_catalog.prsd_headline,
    LEXTYPES = testprs_lextype
);
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-14 09:06:41 +08:00			`/* contrib/test_parser/test_parser--1.0.sql */`
Add sample text search dictionary templates and parsers, to replace the hard-to-maintain textual examples currently in the SGML docs. From Sergey Karpov. 2007-10-16 05:36:50 +08:00
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-13 03:45:03 +08:00			`-- complain if script is sourced in psql, rather than via CREATE EXTENSION`
			`\echo Use "CREATE EXTENSION test_parser" to load this file. \quit`

Avoid use of CREATE OR REPLACE FUNCTION in extension installation files. 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. 2011-02-14 10:24:14 +08:00			`CREATE FUNCTION testprs_start(internal, int4)`
Make /contrib install/uninstall script consistent: 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. 2007-11-11 11:25:35 +08:00			`RETURNS internal`
			`AS 'MODULE_PATHNAME'`
			`LANGUAGE C STRICT;`
Add sample text search dictionary templates and parsers, to replace the hard-to-maintain textual examples currently in the SGML docs. From Sergey Karpov. 2007-10-16 05:36:50 +08:00
Avoid use of CREATE OR REPLACE FUNCTION in extension installation files. 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. 2011-02-14 10:24:14 +08:00			`CREATE FUNCTION testprs_getlexeme(internal, internal, internal)`
Make /contrib install/uninstall script consistent: 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. 2007-11-11 11:25:35 +08:00			`RETURNS internal`
			`AS 'MODULE_PATHNAME'`
			`LANGUAGE C STRICT;`
Add sample text search dictionary templates and parsers, to replace the hard-to-maintain textual examples currently in the SGML docs. From Sergey Karpov. 2007-10-16 05:36:50 +08:00
Avoid use of CREATE OR REPLACE FUNCTION in extension installation files. 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. 2011-02-14 10:24:14 +08:00			`CREATE FUNCTION testprs_end(internal)`
Make /contrib install/uninstall script consistent: 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. 2007-11-11 11:25:35 +08:00			`RETURNS void`
			`AS 'MODULE_PATHNAME'`
			`LANGUAGE C STRICT;`
Add sample text search dictionary templates and parsers, to replace the hard-to-maintain textual examples currently in the SGML docs. From Sergey Karpov. 2007-10-16 05:36:50 +08:00
Avoid use of CREATE OR REPLACE FUNCTION in extension installation files. 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. 2011-02-14 10:24:14 +08:00			`CREATE FUNCTION testprs_lextype(internal)`
Make /contrib install/uninstall script consistent: 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. 2007-11-11 11:25:35 +08:00			`RETURNS internal`
			`AS 'MODULE_PATHNAME'`
			`LANGUAGE C STRICT;`
Add sample text search dictionary templates and parsers, to replace the hard-to-maintain textual examples currently in the SGML docs. From Sergey Karpov. 2007-10-16 05:36:50 +08:00
			`CREATE TEXT SEARCH PARSER testparser (`
			`START = testprs_start,`
			`GETTOKEN = testprs_getlexeme,`
			`END = testprs_end,`
			`HEADLINE = pg_catalog.prsd_headline,`
			`LEXTYPES = testprs_lextype`
			`);`