rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/contrib/tablefunc/tablefunc--1.0.sql

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

89 lines
2.1 KiB
MySQL
Raw Normal View History

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 02:06:41 +01:00
/* contrib/tablefunc/tablefunc--1.0.sql */
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02: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-12 21:45:03 +02:00
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION tablefunc" 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 03:24:14 +01:00
CREATE FUNCTION normal_rand(int4, float8, float8)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof float8
AS 'MODULE_PATHNAME','normal_rand'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C VOLATILE STRICT;
As mentioned above, here is my contrib/tablefunc patch. It includes three functions which exercise the tablefunc API. show_all_settings() - returns the same information as SHOW ALL, but as a query result normal_rand(int numvals, float8 mean, float8 stddev, int seed) - returns a set of normally distributed float8 values - This routine implements Algorithm P (Polar method for normal deviates) from Knuth's _The_Art_of_Computer_Programming_, Volume 2, 3rd ed., pages 122-126. Knuth cites his source as "The polar method", G. E. P. Box, M. E. Muller, and G. Marsaglia, _Annals_Math,_Stat._ 29 (1958), 610-611. crosstabN(text sql) - returns a set of row_name plus N category value columns - crosstab2(), crosstab3(), and crosstab4() are defined for you, but you can create additional crosstab functions per directions in the README. Joe Conway
2002-07-30 18:31:11 +02:00
Document get_call_result_type() and friends; mark TypeGetTupleDesc() and RelationNameGetTupleDesc() as deprecated; remove uses of the latter in the contrib library. Along the way, clean up crosstab() code and documentation a little.
2005-05-31 01:09:07 +02:00
-- the generic crosstab function:
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 03:24:14 +01:00
CREATE FUNCTION crosstab(text)
Document get_call_result_type() and friends; mark TypeGetTupleDesc() and RelationNameGetTupleDesc() as deprecated; remove uses of the latter in the contrib library. Along the way, clean up crosstab() code and documentation a little.
2005-05-31 01:09:07 +02:00
RETURNS setof record
AS 'MODULE_PATHNAME','crosstab'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
Document get_call_result_type() and friends; mark TypeGetTupleDesc() and RelationNameGetTupleDesc() as deprecated; remove uses of the latter in the contrib library. Along the way, clean up crosstab() code and documentation a little.
2005-05-31 01:09:07 +02:00
-- examples of building custom type-specific crosstab functions:
Attached is a patch to fix some recently raised issues that exist in contrib/tablefunc. Specifically it replaces the use of VIEWs (for needed composite type creation) with use of CREATE TYPE. It also performs GRANT EXECUTE ON FUNCTION foo() TO PUBLIC for all of the created functions. There was also a cosmetic change to two regression files. Joe Conway
2002-09-14 21:53:59 +02:00
CREATE TYPE tablefunc_crosstab_2 AS
(
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
row_name TEXT,
category_1 TEXT,
category_2 TEXT
Attached is a patch to fix some recently raised issues that exist in contrib/tablefunc. Specifically it replaces the use of VIEWs (for needed composite type creation) with use of CREATE TYPE. It also performs GRANT EXECUTE ON FUNCTION foo() TO PUBLIC for all of the created functions. There was also a cosmetic change to two regression files. Joe Conway
2002-09-14 21:53:59 +02:00
);
CREATE TYPE tablefunc_crosstab_3 AS
(
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
row_name TEXT,
category_1 TEXT,
category_2 TEXT,
category_3 TEXT
Attached is a patch to fix some recently raised issues that exist in contrib/tablefunc. Specifically it replaces the use of VIEWs (for needed composite type creation) with use of CREATE TYPE. It also performs GRANT EXECUTE ON FUNCTION foo() TO PUBLIC for all of the created functions. There was also a cosmetic change to two regression files. Joe Conway
2002-09-14 21:53:59 +02:00
);
CREATE TYPE tablefunc_crosstab_4 AS
(
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
row_name TEXT,
category_1 TEXT,
category_2 TEXT,
category_3 TEXT,
category_4 TEXT
Attached is a patch to fix some recently raised issues that exist in contrib/tablefunc. Specifically it replaces the use of VIEWs (for needed composite type creation) with use of CREATE TYPE. It also performs GRANT EXECUTE ON FUNCTION foo() TO PUBLIC for all of the created functions. There was also a cosmetic change to two regression files. Joe Conway
2002-09-14 21:53:59 +02:00
);
As mentioned above, here is my contrib/tablefunc patch. It includes three functions which exercise the tablefunc API. show_all_settings() - returns the same information as SHOW ALL, but as a query result normal_rand(int numvals, float8 mean, float8 stddev, int seed) - returns a set of normally distributed float8 values - This routine implements Algorithm P (Polar method for normal deviates) from Knuth's _The_Art_of_Computer_Programming_, Volume 2, 3rd ed., pages 122-126. Knuth cites his source as "The polar method", G. E. P. Box, M. E. Muller, and G. Marsaglia, _Annals_Math,_Stat._ 29 (1958), 610-611. crosstabN(text sql) - returns a set of row_name plus N category value columns - crosstab2(), crosstab3(), and crosstab4() are defined for you, but you can create additional crosstab functions per directions in the README. Joe Conway
2002-07-30 18:31:11 +02: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 03:24:14 +01:00
CREATE FUNCTION crosstab2(text)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof tablefunc_crosstab_2
AS 'MODULE_PATHNAME','crosstab'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
As mentioned above, here is my contrib/tablefunc patch. It includes three functions which exercise the tablefunc API. show_all_settings() - returns the same information as SHOW ALL, but as a query result normal_rand(int numvals, float8 mean, float8 stddev, int seed) - returns a set of normally distributed float8 values - This routine implements Algorithm P (Polar method for normal deviates) from Knuth's _The_Art_of_Computer_Programming_, Volume 2, 3rd ed., pages 122-126. Knuth cites his source as "The polar method", G. E. P. Box, M. E. Muller, and G. Marsaglia, _Annals_Math,_Stat._ 29 (1958), 610-611. crosstabN(text sql) - returns a set of row_name plus N category value columns - crosstab2(), crosstab3(), and crosstab4() are defined for you, but you can create additional crosstab functions per directions in the README. Joe Conway
2002-07-30 18:31:11 +02: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 03:24:14 +01:00
CREATE FUNCTION crosstab3(text)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof tablefunc_crosstab_3
AS 'MODULE_PATHNAME','crosstab'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
As mentioned above, here is my contrib/tablefunc patch. It includes three functions which exercise the tablefunc API. show_all_settings() - returns the same information as SHOW ALL, but as a query result normal_rand(int numvals, float8 mean, float8 stddev, int seed) - returns a set of normally distributed float8 values - This routine implements Algorithm P (Polar method for normal deviates) from Knuth's _The_Art_of_Computer_Programming_, Volume 2, 3rd ed., pages 122-126. Knuth cites his source as "The polar method", G. E. P. Box, M. E. Muller, and G. Marsaglia, _Annals_Math,_Stat._ 29 (1958), 610-611. crosstabN(text sql) - returns a set of row_name plus N category value columns - crosstab2(), crosstab3(), and crosstab4() are defined for you, but you can create additional crosstab functions per directions in the README. Joe Conway
2002-07-30 18:31:11 +02: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 03:24:14 +01:00
CREATE FUNCTION crosstab4(text)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof tablefunc_crosstab_4
AS 'MODULE_PATHNAME','crosstab'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
As mentioned above, here is my contrib/tablefunc patch. It includes three functions which exercise the tablefunc API. show_all_settings() - returns the same information as SHOW ALL, but as a query result normal_rand(int numvals, float8 mean, float8 stddev, int seed) - returns a set of normally distributed float8 values - This routine implements Algorithm P (Polar method for normal deviates) from Knuth's _The_Art_of_Computer_Programming_, Volume 2, 3rd ed., pages 122-126. Knuth cites his source as "The polar method", G. E. P. Box, M. E. Muller, and G. Marsaglia, _Annals_Math,_Stat._ 29 (1958), 610-611. crosstabN(text sql) - returns a set of row_name plus N category value columns - crosstab2(), crosstab3(), and crosstab4() are defined for you, but you can create additional crosstab functions per directions in the README. Joe Conway
2002-07-30 18:31:11 +02:00
Document get_call_result_type() and friends; mark TypeGetTupleDesc() and RelationNameGetTupleDesc() as deprecated; remove uses of the latter in the contrib library. Along the way, clean up crosstab() code and documentation a little.
2005-05-31 01:09:07 +02:00
-- obsolete:
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 03:24:14 +01:00
CREATE FUNCTION crosstab(text,int)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof record
AS 'MODULE_PATHNAME','crosstab'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
Attached is an update to contrib/tablefunc. It introduces a new function, connectby(), which can serve as a reference implementation for the changes made in the last few days -- namely the ability of a function to return an entire tuplestore, and the ability of a function to make use of the query provided "expected" tuple description. Description: connectby(text relname, text keyid_fld, text parent_keyid_fld, text start_with, int max_depth [, text branch_delim]) - returns keyid, parent_keyid, level, and an optional branch string - requires anonymous composite type syntax in the FROM clause. See the instructions in the documentation below. Joe Conway
2002-09-02 07:44:05 +02: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 03:24:14 +01:00
CREATE FUNCTION crosstab(text,text)
Attached is an update to contrib/tablefunc. It implements a new hashed version of crosstab. This fixes a major deficiency in real-world use of the original version. Easiest to undestand with an illustration: Data: ------------------------------------------------------------------- select * from cth; id | rowid | rowdt | attribute | val ----+-------+---------------------+----------------+--------------- 1 | test1 | 2003-03-01 00:00:00 | temperature | 42 2 | test1 | 2003-03-01 00:00:00 | test_result | PASS 3 | test1 | 2003-03-01 00:00:00 | volts | 2.6987 4 | test2 | 2003-03-02 00:00:00 | temperature | 53 5 | test2 | 2003-03-02 00:00:00 | test_result | FAIL 6 | test2 | 2003-03-02 00:00:00 | test_startdate | 01 March 2003 7 | test2 | 2003-03-02 00:00:00 | volts | 3.1234 (7 rows) Original crosstab: ------------------------------------------------------------------- SELECT * FROM crosstab( 'SELECT rowid, attribute, val FROM cth ORDER BY 1,2',4) AS c(rowid text, temperature text, test_result text, test_startdate text, volts text); rowid | temperature | test_result | test_startdate | volts -------+-------------+-------------+----------------+-------- test1 | 42 | PASS | 2.6987 | test2 | 53 | FAIL | 01 March 2003 | 3.1234 (2 rows) Hashed crosstab: ------------------------------------------------------------------- SELECT * FROM crosstab( 'SELECT rowid, attribute, val FROM cth ORDER BY 1', 'SELECT DISTINCT attribute FROM cth ORDER BY 1') AS c(rowid text, temperature int4, test_result text, test_startdate timestamp, volts float8); rowid | temperature | test_result | test_startdate | volts -------+-------------+-------------+---------------------+-------- test1 | 42 | PASS | | 2.6987 test2 | 53 | FAIL | 2003-03-01 00:00:00 | 3.1234 (2 rows) Notice that the original crosstab slides data over to the left in the result tuple when it encounters missing data. In order to work around this you have to be make your source sql do all sorts of contortions (cartesian join of distinct rowid with distinct attribute; left join that back to the real source data). The new version avoids this by building a hash table using a second distinct attribute query. The new version also allows for "extra" columns (see the README) and allows the result columns to be coerced into differing datatypes if they are suitable (as shown above). In testing a "real-world" data set (69 distinct rowid's, 27 distinct categories/attributes, multiple missing data points) I saw about a 5-fold improvement in execution time (from about 2200 ms old, to 440 ms new). I left the original version intact because: 1) BC, 2) it is probably slightly faster if you know that you have no missing attributes. README and regression test adjustments included. If there are no objections, please apply. Joe Conway
2003-03-20 07:46:30 +01:00
RETURNS setof record
AS 'MODULE_PATHNAME','crosstab_hash'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
Attached is an update to contrib/tablefunc. It implements a new hashed version of crosstab. This fixes a major deficiency in real-world use of the original version. Easiest to undestand with an illustration: Data: ------------------------------------------------------------------- select * from cth; id | rowid | rowdt | attribute | val ----+-------+---------------------+----------------+--------------- 1 | test1 | 2003-03-01 00:00:00 | temperature | 42 2 | test1 | 2003-03-01 00:00:00 | test_result | PASS 3 | test1 | 2003-03-01 00:00:00 | volts | 2.6987 4 | test2 | 2003-03-02 00:00:00 | temperature | 53 5 | test2 | 2003-03-02 00:00:00 | test_result | FAIL 6 | test2 | 2003-03-02 00:00:00 | test_startdate | 01 March 2003 7 | test2 | 2003-03-02 00:00:00 | volts | 3.1234 (7 rows) Original crosstab: ------------------------------------------------------------------- SELECT * FROM crosstab( 'SELECT rowid, attribute, val FROM cth ORDER BY 1,2',4) AS c(rowid text, temperature text, test_result text, test_startdate text, volts text); rowid | temperature | test_result | test_startdate | volts -------+-------------+-------------+----------------+-------- test1 | 42 | PASS | 2.6987 | test2 | 53 | FAIL | 01 March 2003 | 3.1234 (2 rows) Hashed crosstab: ------------------------------------------------------------------- SELECT * FROM crosstab( 'SELECT rowid, attribute, val FROM cth ORDER BY 1', 'SELECT DISTINCT attribute FROM cth ORDER BY 1') AS c(rowid text, temperature int4, test_result text, test_startdate timestamp, volts float8); rowid | temperature | test_result | test_startdate | volts -------+-------------+-------------+---------------------+-------- test1 | 42 | PASS | | 2.6987 test2 | 53 | FAIL | 2003-03-01 00:00:00 | 3.1234 (2 rows) Notice that the original crosstab slides data over to the left in the result tuple when it encounters missing data. In order to work around this you have to be make your source sql do all sorts of contortions (cartesian join of distinct rowid with distinct attribute; left join that back to the real source data). The new version avoids this by building a hash table using a second distinct attribute query. The new version also allows for "extra" columns (see the README) and allows the result columns to be coerced into differing datatypes if they are suitable (as shown above). In testing a "real-world" data set (69 distinct rowid's, 27 distinct categories/attributes, multiple missing data points) I saw about a 5-fold improvement in execution time (from about 2200 ms old, to 440 ms new). I left the original version intact because: 1) BC, 2) it is probably slightly faster if you know that you have no missing attributes. README and regression test adjustments included. If there are no objections, please apply. Joe Conway
2003-03-20 07:46:30 +01: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 03:24:14 +01:00
CREATE FUNCTION connectby(text,text,text,text,int,text)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof record
AS 'MODULE_PATHNAME','connectby_text'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
Attached is an update to contrib/tablefunc. It introduces a new function, connectby(), which can serve as a reference implementation for the changes made in the last few days -- namely the ability of a function to return an entire tuplestore, and the ability of a function to make use of the query provided "expected" tuple description. Description: connectby(text relname, text keyid_fld, text parent_keyid_fld, text start_with, int max_depth [, text branch_delim]) - returns keyid, parent_keyid, level, and an optional branch string - requires anonymous composite type syntax in the FROM clause. See the instructions in the documentation below. Joe Conway
2002-09-02 07:44:05 +02: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 03:24:14 +01:00
CREATE FUNCTION connectby(text,text,text,text,int)
Update /contrib for "autocommit TO 'on'". Create objects in public schema. Make spacing/capitalization consistent. Remove transaction block use for object creation. Remove unneeded function GRANTs.
2002-10-18 20:41:22 +02:00
RETURNS setof record
AS 'MODULE_PATHNAME','connectby_text'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
> Am Son, 2003-06-22 um 02.09 schrieb Joe Conway: >>Sounds like all that's needed for your case. But to be complete, in >>addition to changing tablefunc.c we'd have to: >>1) come up with a new function call signature that makes sense and does >>not cause backward compatibility problems for other people >>2) make needed changes to tablefunc.sql.in >>3) adjust the README.tablefunc appropriately >>4) adjust the regression test for new functionality >>5) be sure we don't break any of the old cases >> >>If you want to submit a complete patch, it would be gratefully accepted >>-- for review at least ;-) > > Here's the patch, at least for steps 1-3 Nabil Sayegh Joe Conway
2003-07-27 05:51:59 +02:00
-- These 2 take the name of a field to ORDER BY as 4th arg (for sorting siblings)
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 03:24:14 +01:00
CREATE FUNCTION connectby(text,text,text,text,text,int,text)
> Am Son, 2003-06-22 um 02.09 schrieb Joe Conway: >>Sounds like all that's needed for your case. But to be complete, in >>addition to changing tablefunc.c we'd have to: >>1) come up with a new function call signature that makes sense and does >>not cause backward compatibility problems for other people >>2) make needed changes to tablefunc.sql.in >>3) adjust the README.tablefunc appropriately >>4) adjust the regression test for new functionality >>5) be sure we don't break any of the old cases >> >>If you want to submit a complete patch, it would be gratefully accepted >>-- for review at least ;-) > > Here's the patch, at least for steps 1-3 Nabil Sayegh Joe Conway
2003-07-27 05:51:59 +02:00
RETURNS setof record
AS 'MODULE_PATHNAME','connectby_text_serial'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;
> Am Son, 2003-06-22 um 02.09 schrieb Joe Conway: >>Sounds like all that's needed for your case. But to be complete, in >>addition to changing tablefunc.c we'd have to: >>1) come up with a new function call signature that makes sense and does >>not cause backward compatibility problems for other people >>2) make needed changes to tablefunc.sql.in >>3) adjust the README.tablefunc appropriately >>4) adjust the regression test for new functionality >>5) be sure we don't break any of the old cases >> >>If you want to submit a complete patch, it would be gratefully accepted >>-- for review at least ;-) > > Here's the patch, at least for steps 1-3 Nabil Sayegh Joe Conway
2003-07-27 05:51:59 +02: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 03:24:14 +01:00
CREATE FUNCTION connectby(text,text,text,text,text,int)
> Am Son, 2003-06-22 um 02.09 schrieb Joe Conway: >>Sounds like all that's needed for your case. But to be complete, in >>addition to changing tablefunc.c we'd have to: >>1) come up with a new function call signature that makes sense and does >>not cause backward compatibility problems for other people >>2) make needed changes to tablefunc.sql.in >>3) adjust the README.tablefunc appropriately >>4) adjust the regression test for new functionality >>5) be sure we don't break any of the old cases >> >>If you want to submit a complete patch, it would be gratefully accepted >>-- for review at least ;-) > > Here's the patch, at least for steps 1-3 Nabil Sayegh Joe Conway
2003-07-27 05:51:59 +02:00
RETURNS setof record
AS 'MODULE_PATHNAME','connectby_text_serial'
Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, in particular get rid of single quotes around language names and old WITH () construct.
2006-02-27 17:09:50 +01:00
LANGUAGE C STABLE STRICT;