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-31 00:31:11 +08:00
|
|
|
/*
|
|
|
|
* tablefunc
|
|
|
|
*
|
|
|
|
* Sample to demonstrate C functions which return setof scalar
|
|
|
|
* and setof composite.
|
|
|
|
* Joe Conway <mail@joeconway.com>
|
|
|
|
*
|
|
|
|
* Copyright 2002 by PostgreSQL Global Development Group
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, and distribute this software and its
|
|
|
|
* documentation for any purpose, without fee, and without a written agreement
|
|
|
|
* is hereby granted, provided that the above copyright notice and this
|
|
|
|
* paragraph and the following two paragraphs appear in all copies.
|
2002-09-05 04:31:48 +08: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-31 00:31:11 +08:00
|
|
|
* IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR
|
|
|
|
* DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
|
|
|
|
* LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
|
|
|
|
* DOCUMENTATION, EVEN IF THE AUTHOR OR DISTRIBUTORS HAVE BEEN ADVISED OF THE
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
2002-09-05 04:31:48 +08: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-31 00:31:11 +08:00
|
|
|
* THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,
|
|
|
|
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
|
|
|
|
* AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
|
|
|
|
* ON AN "AS IS" BASIS, AND THE AUTHOR AND DISTRIBUTORS HAS NO OBLIGATIONS TO
|
|
|
|
* PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2002-09-05 08:43:07 +08:00
|
|
|
#include <math.h>
|
|
|
|
|
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-31 00:31:11 +08:00
|
|
|
#include "fmgr.h"
|
|
|
|
#include "funcapi.h"
|
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 13:44:05 +08:00
|
|
|
#include "executor/spi.h"
|
|
|
|
#include "miscadmin.h"
|
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-31 00:31:11 +08:00
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/guc.h"
|
2002-08-15 10:51:27 +08:00
|
|
|
#include "utils/lsyscache.h"
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
#include "tablefunc.h"
|
|
|
|
|
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 14:46:30 +08:00
|
|
|
static int load_categories_hash(char *cats_sql, MemoryContext per_query_ctx);
|
|
|
|
static Tuplestorestate *get_crosstab_tuplestore(char *sql,
|
|
|
|
int num_categories,
|
|
|
|
TupleDesc tupdesc,
|
|
|
|
MemoryContext per_query_ctx);
|
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 13:44:05 +08:00
|
|
|
static void validateConnectbyTupleDesc(TupleDesc tupdesc, bool show_branch);
|
|
|
|
static bool compatCrosstabTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2);
|
|
|
|
static bool compatConnectbyTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2);
|
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-31 00:31:11 +08:00
|
|
|
static void get_normal_pair(float8 *x1, float8 *x2);
|
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 13:44:05 +08:00
|
|
|
static TupleDesc make_crosstab_tupledesc(TupleDesc spi_tupdesc,
|
2003-03-11 06:28:22 +08:00
|
|
|
int num_categories);
|
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 13:44:05 +08:00
|
|
|
static Tuplestorestate *connectby(char *relname,
|
2002-09-05 04:31:48 +08:00
|
|
|
char *key_fld,
|
|
|
|
char *parent_key_fld,
|
|
|
|
char *branch_delim,
|
|
|
|
char *start_with,
|
|
|
|
int max_depth,
|
|
|
|
bool show_branch,
|
|
|
|
MemoryContext per_query_ctx,
|
|
|
|
AttInMetadata *attinmeta);
|
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 13:44:05 +08:00
|
|
|
static Tuplestorestate *build_tuplestore_recursively(char *key_fld,
|
2002-09-05 04:31:48 +08:00
|
|
|
char *parent_key_fld,
|
|
|
|
char *relname,
|
|
|
|
char *branch_delim,
|
|
|
|
char *start_with,
|
|
|
|
char *branch,
|
|
|
|
int level,
|
|
|
|
int max_depth,
|
|
|
|
bool show_branch,
|
|
|
|
MemoryContext per_query_ctx,
|
|
|
|
AttInMetadata *attinmeta,
|
|
|
|
Tuplestorestate *tupstore);
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
float8 mean; /* mean of the distribution */
|
|
|
|
float8 stddev; /* stddev of the distribution */
|
|
|
|
float8 carry_val; /* hold second generated value */
|
|
|
|
bool use_carry; /* use second generated value */
|
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-31 00:31:11 +08:00
|
|
|
} normal_rand_fctx;
|
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
SPITupleTable *spi_tuptable; /* sql results from user query */
|
|
|
|
char *lastrowid; /* rowid of the last tuple sent */
|
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-31 00:31:11 +08:00
|
|
|
} crosstab_fctx;
|
|
|
|
|
|
|
|
#define GET_TEXT(cstrp) DatumGetTextP(DirectFunctionCall1(textin, CStringGetDatum(cstrp)))
|
|
|
|
#define GET_STR(textp) DatumGetCString(DirectFunctionCall1(textout, PointerGetDatum(textp)))
|
|
|
|
#define xpfree(var_) \
|
|
|
|
do { \
|
|
|
|
if (var_ != NULL) \
|
|
|
|
{ \
|
|
|
|
pfree(var_); \
|
|
|
|
var_ = NULL; \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
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 13:44:05 +08:00
|
|
|
/* sign, 10 digits, '\0' */
|
|
|
|
#define INT32_STRLEN 12
|
|
|
|
|
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 14:46:30 +08:00
|
|
|
/* hash table support */
|
|
|
|
static HTAB *crosstab_HashTable;
|
|
|
|
|
|
|
|
/* The information we cache about loaded procedures */
|
|
|
|
typedef struct crosstab_cat_desc
|
|
|
|
{
|
|
|
|
char *catname;
|
|
|
|
int attidx; /* zero based */
|
|
|
|
} crosstab_cat_desc;
|
|
|
|
|
|
|
|
#define MAX_CATNAME_LEN NAMEDATALEN
|
|
|
|
#define INIT_CATS 64
|
|
|
|
|
|
|
|
#define crosstab_HashTableLookup(CATNAME, CATDESC) \
|
|
|
|
do { \
|
|
|
|
crosstab_HashEnt *hentry; char key[MAX_CATNAME_LEN]; \
|
|
|
|
\
|
|
|
|
MemSet(key, 0, MAX_CATNAME_LEN); \
|
|
|
|
snprintf(key, MAX_CATNAME_LEN - 1, "%s", CATNAME); \
|
|
|
|
hentry = (crosstab_HashEnt*) hash_search(crosstab_HashTable, \
|
|
|
|
key, HASH_FIND, NULL); \
|
|
|
|
if (hentry) \
|
|
|
|
CATDESC = hentry->catdesc; \
|
|
|
|
else \
|
|
|
|
CATDESC = NULL; \
|
|
|
|
} while(0)
|
|
|
|
|
|
|
|
#define crosstab_HashTableInsert(CATDESC) \
|
|
|
|
do { \
|
|
|
|
crosstab_HashEnt *hentry; bool found; char key[MAX_CATNAME_LEN]; \
|
|
|
|
\
|
|
|
|
MemSet(key, 0, MAX_CATNAME_LEN); \
|
|
|
|
snprintf(key, MAX_CATNAME_LEN - 1, "%s", CATDESC->catname); \
|
|
|
|
hentry = (crosstab_HashEnt*) hash_search(crosstab_HashTable, \
|
|
|
|
key, HASH_ENTER, &found); \
|
|
|
|
if (hentry == NULL) \
|
|
|
|
elog(ERROR, "out of memory in crosstab_HashTable"); \
|
|
|
|
if (found) \
|
|
|
|
elog(ERROR, "trying to use a category name more than once"); \
|
|
|
|
hentry->catdesc = CATDESC; \
|
|
|
|
} while(0)
|
|
|
|
|
|
|
|
#define crosstab_HashTableDelete(CATNAME) \
|
|
|
|
do { \
|
|
|
|
crosstab_HashEnt *hentry; char key[MAX_CATNAME_LEN]; \
|
|
|
|
\
|
|
|
|
MemSet(key, 0, MAX_CATNAME_LEN); \
|
|
|
|
snprintf(key, MAX_CATNAME_LEN - 1, "%s", CATNAME); \
|
|
|
|
hentry = (crosstab_HashEnt*) hash_search(crosstab_HashTable, \
|
|
|
|
key, HASH_REMOVE, NULL); \
|
|
|
|
if (hentry == NULL) \
|
|
|
|
elog(WARNING, "trying to delete function name that does not exist."); \
|
|
|
|
} while(0)
|
|
|
|
|
|
|
|
/* hash table */
|
|
|
|
typedef struct crosstab_hashent
|
|
|
|
{
|
|
|
|
char internal_catname[MAX_CATNAME_LEN];
|
|
|
|
crosstab_cat_desc *catdesc;
|
|
|
|
} crosstab_HashEnt;
|
|
|
|
|
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-31 00:31:11 +08:00
|
|
|
/*
|
|
|
|
* normal_rand - return requested number of random values
|
|
|
|
* with a Gaussian (Normal) distribution.
|
|
|
|
*
|
|
|
|
* inputs are int numvals, float8 lower_bound, and float8 upper_bound
|
|
|
|
* returns float8
|
|
|
|
*/
|
|
|
|
PG_FUNCTION_INFO_V1(normal_rand);
|
|
|
|
Datum
|
|
|
|
normal_rand(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
FuncCallContext *funcctx;
|
|
|
|
int call_cntr;
|
|
|
|
int max_calls;
|
|
|
|
normal_rand_fctx *fctx;
|
|
|
|
float8 mean;
|
|
|
|
float8 stddev;
|
|
|
|
float8 carry_val;
|
|
|
|
bool use_carry;
|
|
|
|
MemoryContext oldcontext;
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* stuff done only on the first call of the function */
|
2002-09-05 04:31:48 +08:00
|
|
|
if (SRF_IS_FIRSTCALL())
|
|
|
|
{
|
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-31 00:31:11 +08:00
|
|
|
/* create a function context for cross-call persistence */
|
2002-09-05 04:31:48 +08:00
|
|
|
funcctx = SRF_FIRSTCALL_INIT();
|
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-31 00:31:11 +08:00
|
|
|
|
2002-09-05 04:31:48 +08:00
|
|
|
/*
|
|
|
|
* switch to memory context appropriate for multiple function
|
|
|
|
* calls
|
|
|
|
*/
|
2002-08-30 01:14:33 +08:00
|
|
|
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
|
|
|
|
|
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-31 00:31:11 +08:00
|
|
|
/* total number of tuples to be returned */
|
|
|
|
funcctx->max_calls = PG_GETARG_UINT32(0);
|
|
|
|
|
|
|
|
/* allocate memory for user context */
|
|
|
|
fctx = (normal_rand_fctx *) palloc(sizeof(normal_rand_fctx));
|
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* Use fctx to keep track of upper and lower bounds from call to
|
|
|
|
* call. It will also be used to carry over the spare value we get
|
|
|
|
* from the Box-Muller algorithm so that we only actually
|
|
|
|
* calculate a new value every other call.
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
fctx->mean = PG_GETARG_FLOAT8(1);
|
|
|
|
fctx->stddev = PG_GETARG_FLOAT8(2);
|
|
|
|
fctx->carry_val = 0;
|
|
|
|
fctx->use_carry = false;
|
|
|
|
|
|
|
|
funcctx->user_fctx = fctx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* we might actually get passed a negative number, but for this
|
|
|
|
* purpose it doesn't matter, just cast it as an unsigned value
|
|
|
|
*/
|
|
|
|
srandom(PG_GETARG_UINT32(3));
|
2002-08-30 01:14:33 +08:00
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
2002-09-05 04:31:48 +08: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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* stuff done on every call of the function */
|
2002-09-05 04:31:48 +08:00
|
|
|
funcctx = SRF_PERCALL_SETUP();
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
call_cntr = funcctx->call_cntr;
|
|
|
|
max_calls = funcctx->max_calls;
|
|
|
|
fctx = funcctx->user_fctx;
|
|
|
|
mean = fctx->mean;
|
|
|
|
stddev = fctx->stddev;
|
|
|
|
carry_val = fctx->carry_val;
|
|
|
|
use_carry = fctx->use_carry;
|
2002-09-05 04:31:48 +08:00
|
|
|
|
|
|
|
if (call_cntr < max_calls) /* do when there is more left to send */
|
|
|
|
{
|
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-31 00:31:11 +08:00
|
|
|
float8 result;
|
|
|
|
|
2002-09-05 04:31:48 +08:00
|
|
|
if (use_carry)
|
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-31 00:31:11 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* reset use_carry and use second value obtained on last pass
|
|
|
|
*/
|
|
|
|
fctx->use_carry = false;
|
|
|
|
result = carry_val;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
float8 normval_1;
|
|
|
|
float8 normval_2;
|
|
|
|
|
|
|
|
/* Get the next two normal values */
|
|
|
|
get_normal_pair(&normval_1, &normval_2);
|
|
|
|
|
|
|
|
/* use the first */
|
|
|
|
result = mean + (stddev * normval_1);
|
|
|
|
|
|
|
|
/* and save the second */
|
|
|
|
fctx->carry_val = mean + (stddev * normval_2);
|
|
|
|
fctx->use_carry = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* send the result */
|
2002-09-05 04:31:48 +08:00
|
|
|
SRF_RETURN_NEXT(funcctx, Float8GetDatum(result));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
/* do when there is no more left */
|
|
|
|
SRF_RETURN_DONE(funcctx);
|
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-31 00:31:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get_normal_pair()
|
|
|
|
* Assigns normally distributed (Gaussian) values to a pair of provided
|
|
|
|
* parameters, with mean 0, standard deviation 1.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
get_normal_pair(float8 *x1, float8 *x2)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
float8 u1,
|
|
|
|
u2,
|
|
|
|
v1,
|
|
|
|
v2,
|
|
|
|
s;
|
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-31 00:31:11 +08:00
|
|
|
|
2002-09-15 03:32:54 +08:00
|
|
|
do
|
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-31 00:31:11 +08:00
|
|
|
{
|
2002-09-15 03:32:54 +08:00
|
|
|
u1 = (float8) random() / (float8) MAX_RANDOM_VALUE;
|
|
|
|
u2 = (float8) random() / (float8) MAX_RANDOM_VALUE;
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
v1 = (2.0 * u1) - 1.0;
|
|
|
|
v2 = (2.0 * u2) - 1.0;
|
|
|
|
|
2002-09-15 03:32:54 +08:00
|
|
|
s = v1 * v1 + v2 * v2;
|
|
|
|
} while (s >= 1.0);
|
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-31 00:31:11 +08:00
|
|
|
|
2002-09-15 03:32:54 +08:00
|
|
|
if (s == 0)
|
|
|
|
{
|
|
|
|
*x1 = 0;
|
|
|
|
*x2 = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
s = sqrt((-2.0 * log(s)) / s);
|
|
|
|
*x1 = v1 * s;
|
|
|
|
*x2 = v2 * s;
|
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-31 00:31:11 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* crosstab - create a crosstab of rowids and values columns from a
|
|
|
|
* SQL statement returning one rowid column, one category column,
|
|
|
|
* and one value column.
|
|
|
|
*
|
|
|
|
* e.g. given sql which produces:
|
|
|
|
*
|
|
|
|
* rowid cat value
|
|
|
|
* ------+-------+-------
|
2002-09-05 04:31:48 +08:00
|
|
|
* row1 cat1 val1
|
|
|
|
* row1 cat2 val2
|
|
|
|
* row1 cat3 val3
|
|
|
|
* row1 cat4 val4
|
|
|
|
* row2 cat1 val5
|
|
|
|
* row2 cat2 val6
|
|
|
|
* row2 cat3 val7
|
|
|
|
* row2 cat4 val8
|
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-31 00:31:11 +08:00
|
|
|
*
|
|
|
|
* crosstab returns:
|
|
|
|
* <===== values columns =====>
|
|
|
|
* rowid cat1 cat2 cat3 cat4
|
|
|
|
* ------+-------+-------+-------+-------
|
2002-09-05 04:31:48 +08:00
|
|
|
* row1 val1 val2 val3 val4
|
|
|
|
* row2 val5 val6 val7 val8
|
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-31 00:31:11 +08:00
|
|
|
*
|
|
|
|
* NOTES:
|
|
|
|
* 1. SQL result must be ordered by 1,2.
|
|
|
|
* 2. The number of values columns depends on the tuple description
|
2002-09-05 04:31:48 +08:00
|
|
|
* of the function's declared return type.
|
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-31 00:31:11 +08:00
|
|
|
* 2. Missing values (i.e. not enough adjacent rows of same rowid to
|
2002-09-05 04:31:48 +08:00
|
|
|
* fill the number of result values columns) are filled in with nulls.
|
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-31 00:31:11 +08:00
|
|
|
* 3. Extra values (i.e. too many adjacent rows of same rowid to fill
|
2002-09-05 04:31:48 +08:00
|
|
|
* the number of result values columns) are skipped.
|
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-31 00:31:11 +08:00
|
|
|
* 4. Rows with all nulls in the values columns are skipped.
|
|
|
|
*/
|
|
|
|
PG_FUNCTION_INFO_V1(crosstab);
|
|
|
|
Datum
|
|
|
|
crosstab(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
FuncCallContext *funcctx;
|
|
|
|
TupleDesc ret_tupdesc;
|
|
|
|
int call_cntr;
|
|
|
|
int max_calls;
|
|
|
|
TupleTableSlot *slot;
|
|
|
|
AttInMetadata *attinmeta;
|
|
|
|
SPITupleTable *spi_tuptable = NULL;
|
|
|
|
TupleDesc spi_tupdesc;
|
|
|
|
char *lastrowid = NULL;
|
|
|
|
crosstab_fctx *fctx;
|
|
|
|
int i;
|
|
|
|
int num_categories;
|
|
|
|
MemoryContext oldcontext;
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* stuff done only on the first call of the function */
|
2002-09-05 04:31:48 +08:00
|
|
|
if (SRF_IS_FIRSTCALL())
|
|
|
|
{
|
|
|
|
char *sql = GET_STR(PG_GETARG_TEXT_P(0));
|
|
|
|
Oid funcid = fcinfo->flinfo->fn_oid;
|
|
|
|
Oid functypeid;
|
|
|
|
char functyptype;
|
|
|
|
TupleDesc tupdesc = NULL;
|
|
|
|
int ret;
|
|
|
|
int proc;
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* create a function context for cross-call persistence */
|
2002-09-05 04:31:48 +08:00
|
|
|
funcctx = SRF_FIRSTCALL_INIT();
|
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-31 00:31:11 +08:00
|
|
|
|
2002-09-05 04:31:48 +08:00
|
|
|
/*
|
|
|
|
* switch to memory context appropriate for multiple function
|
|
|
|
* calls
|
|
|
|
*/
|
2002-08-30 01:14:33 +08:00
|
|
|
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* Connect to SPI manager */
|
|
|
|
if ((ret = SPI_connect()) < 0)
|
|
|
|
elog(ERROR, "crosstab: SPI_connect returned %d", ret);
|
|
|
|
|
|
|
|
/* Retrieve the desired rows */
|
|
|
|
ret = SPI_exec(sql, 0);
|
|
|
|
proc = SPI_processed;
|
|
|
|
|
|
|
|
/* Check for qualifying tuples */
|
|
|
|
if ((ret == SPI_OK_SELECT) && (proc > 0))
|
|
|
|
{
|
|
|
|
spi_tuptable = SPI_tuptable;
|
|
|
|
spi_tupdesc = spi_tuptable->tupdesc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The provided SQL query must always return three columns.
|
|
|
|
*
|
2002-08-15 10:51:27 +08:00
|
|
|
* 1. rowname the label or identifier for each row in the final
|
2002-09-05 04:31:48 +08:00
|
|
|
* result 2. category the label or identifier for each column
|
|
|
|
* in the final result 3. values the value for each column
|
|
|
|
* in the final result
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
if (spi_tupdesc->natts != 3)
|
|
|
|
elog(ERROR, "crosstab: provided SQL must return 3 columns;"
|
2002-09-05 04:31:48 +08:00
|
|
|
" a rowid, a category, and a values column");
|
2002-08-15 10:51:27 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* no qualifying tuples */
|
|
|
|
SPI_finish();
|
2002-09-05 04:31:48 +08:00
|
|
|
SRF_RETURN_DONE(funcctx);
|
2002-08-15 10:51:27 +08: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-31 00:31:11 +08:00
|
|
|
|
2002-08-30 01:14:33 +08:00
|
|
|
/* SPI switches context on us, so reset it */
|
|
|
|
MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
|
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-31 00:31:11 +08:00
|
|
|
|
2002-08-15 10:51:27 +08:00
|
|
|
/* get the typeid that represents our return type */
|
|
|
|
functypeid = get_func_rettype(funcid);
|
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-31 00:31:11 +08:00
|
|
|
|
2002-08-15 10:51:27 +08:00
|
|
|
/* check typtype to see if we have a predetermined return type */
|
|
|
|
functyptype = get_typtype(functypeid);
|
2002-09-05 04:31:48 +08:00
|
|
|
|
2002-08-15 10:51:27 +08:00
|
|
|
if (functyptype == 'c')
|
|
|
|
{
|
|
|
|
/* Build a tuple description for a functypeid tuple */
|
|
|
|
tupdesc = TypeGetTupleDesc(functypeid, NIL);
|
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-31 00:31:11 +08:00
|
|
|
}
|
2002-08-15 10:51:27 +08:00
|
|
|
else if (functyptype == 'p' && functypeid == RECORDOID)
|
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-31 00:31:11 +08:00
|
|
|
{
|
2002-08-15 10:51:27 +08:00
|
|
|
if (fcinfo->nargs != 2)
|
|
|
|
elog(ERROR, "Wrong number of arguments specified for function");
|
|
|
|
else
|
|
|
|
{
|
2003-03-11 06:28:22 +08:00
|
|
|
int num_categories = PG_GETARG_INT32(1);
|
2002-08-15 10:51:27 +08:00
|
|
|
|
2003-03-11 06:28:22 +08:00
|
|
|
tupdesc = make_crosstab_tupledesc(spi_tupdesc, num_categories);
|
2002-08-15 10:51:27 +08: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-31 00:31:11 +08:00
|
|
|
}
|
2002-08-15 10:51:27 +08:00
|
|
|
else if (functyptype == 'b')
|
|
|
|
elog(ERROR, "Invalid kind of return type specified for function");
|
|
|
|
else
|
|
|
|
elog(ERROR, "Unknown kind of return type specified for function");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that return tupdesc is compatible with the one we got
|
|
|
|
* from ret_relname, at least based on number and type of
|
|
|
|
* attributes
|
|
|
|
*/
|
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 13:44:05 +08:00
|
|
|
if (!compatCrosstabTupleDescs(tupdesc, spi_tupdesc))
|
2002-08-15 10:51:27 +08:00
|
|
|
elog(ERROR, "crosstab: return and sql tuple descriptions are"
|
2002-09-05 04:31:48 +08:00
|
|
|
" incompatible");
|
2002-08-15 10:51:27 +08:00
|
|
|
|
|
|
|
/* allocate a slot for a tuple with this tupdesc */
|
|
|
|
slot = TupleDescGetSlot(tupdesc);
|
|
|
|
|
|
|
|
/* assign slot to function context */
|
|
|
|
funcctx->slot = slot;
|
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* Generate attribute metadata needed later to produce tuples from
|
|
|
|
* raw C strings
|
2002-08-15 10:51:27 +08:00
|
|
|
*/
|
|
|
|
attinmeta = TupleDescGetAttInMetadata(tupdesc);
|
|
|
|
funcctx->attinmeta = attinmeta;
|
|
|
|
|
|
|
|
/* allocate memory for user context */
|
|
|
|
fctx = (crosstab_fctx *) palloc(sizeof(crosstab_fctx));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Save spi data for use across calls
|
|
|
|
*/
|
|
|
|
fctx->spi_tuptable = spi_tuptable;
|
|
|
|
fctx->lastrowid = NULL;
|
|
|
|
funcctx->user_fctx = fctx;
|
|
|
|
|
|
|
|
/* total number of tuples to be returned */
|
|
|
|
funcctx->max_calls = proc;
|
2002-08-30 01:14:33 +08:00
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
2002-09-05 04:31:48 +08: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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* stuff done on every call of the function */
|
2002-09-05 04:31:48 +08:00
|
|
|
funcctx = SRF_PERCALL_SETUP();
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* initialize per-call variables
|
|
|
|
*/
|
|
|
|
call_cntr = funcctx->call_cntr;
|
|
|
|
max_calls = funcctx->max_calls;
|
|
|
|
|
|
|
|
/* return slot for our tuple */
|
|
|
|
slot = funcctx->slot;
|
|
|
|
|
|
|
|
/* user context info */
|
|
|
|
fctx = (crosstab_fctx *) funcctx->user_fctx;
|
|
|
|
lastrowid = fctx->lastrowid;
|
|
|
|
spi_tuptable = fctx->spi_tuptable;
|
|
|
|
|
|
|
|
/* the sql tuple */
|
|
|
|
spi_tupdesc = spi_tuptable->tupdesc;
|
|
|
|
|
|
|
|
/* attribute return type and return tuple description */
|
|
|
|
attinmeta = funcctx->attinmeta;
|
|
|
|
ret_tupdesc = attinmeta->tupdesc;
|
|
|
|
|
|
|
|
/* the return tuple always must have 1 rowid + num_categories columns */
|
|
|
|
num_categories = ret_tupdesc->natts - 1;
|
2002-09-05 04:31:48 +08: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-31 00:31:11 +08:00
|
|
|
if (call_cntr < max_calls) /* do when there is more left to send */
|
2002-09-05 04:31:48 +08: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-31 00:31:11 +08:00
|
|
|
HeapTuple tuple;
|
|
|
|
Datum result;
|
|
|
|
char **values;
|
|
|
|
bool allnulls = true;
|
|
|
|
|
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
/* allocate space */
|
|
|
|
values = (char **) palloc((1 + num_categories) * sizeof(char *));
|
|
|
|
|
|
|
|
/* and make sure it's clear */
|
|
|
|
memset(values, '\0', (1 + num_categories) * sizeof(char *));
|
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* now loop through the sql results and assign each value in
|
|
|
|
* sequence to the next category
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
for (i = 0; i < num_categories; i++)
|
|
|
|
{
|
|
|
|
HeapTuple spi_tuple;
|
2002-08-30 01:14:33 +08:00
|
|
|
char *rowid = NULL;
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* see if we've gone too far already */
|
|
|
|
if (call_cntr >= max_calls)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* get the next sql result tuple */
|
|
|
|
spi_tuple = spi_tuptable->vals[call_cntr];
|
|
|
|
|
|
|
|
/* get the rowid from the current sql result tuple */
|
|
|
|
rowid = SPI_getvalue(spi_tuple, spi_tupdesc, 1);
|
|
|
|
|
2002-09-05 04:31:48 +08:00
|
|
|
/*
|
|
|
|
* If this is the first pass through the values for this
|
|
|
|
* rowid set it, otherwise make sure it hasn't changed on
|
|
|
|
* us. Also check to see if the rowid is the same as that
|
|
|
|
* of the last tuple sent -- if so, skip this tuple
|
|
|
|
* entirely
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
if (i == 0)
|
|
|
|
values[0] = pstrdup(rowid);
|
|
|
|
|
|
|
|
if ((rowid != NULL) && (strcmp(rowid, values[0]) == 0))
|
|
|
|
{
|
|
|
|
if ((lastrowid != NULL) && (strcmp(rowid, lastrowid) == 0))
|
|
|
|
break;
|
|
|
|
else if (allnulls == true)
|
|
|
|
allnulls = false;
|
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* Get the next category item value, which is alway
|
|
|
|
* attribute number three.
|
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-31 00:31:11 +08:00
|
|
|
*
|
2002-09-05 04:31:48 +08:00
|
|
|
* Be careful to sssign the value to the array index
|
|
|
|
* based on which category we are presently
|
|
|
|
* processing.
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
values[1 + i] = SPI_getvalue(spi_tuple, spi_tupdesc, 3);
|
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* increment the counter since we consume a row for
|
|
|
|
* each category, but not for last pass because the
|
|
|
|
* API will do that for us
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
if (i < (num_categories - 1))
|
|
|
|
call_cntr = ++funcctx->call_cntr;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* We'll fill in NULLs for the missing values, but we
|
|
|
|
* need to decrement the counter since this sql result
|
|
|
|
* row doesn't belong to the current output tuple.
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
call_cntr = --funcctx->call_cntr;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rowid != NULL)
|
|
|
|
xpfree(rowid);
|
|
|
|
}
|
|
|
|
|
|
|
|
xpfree(fctx->lastrowid);
|
|
|
|
|
|
|
|
if (values[0] != NULL)
|
2002-08-30 01:14:33 +08:00
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
/*
|
|
|
|
* switch to memory context appropriate for multiple
|
|
|
|
* function calls
|
|
|
|
*/
|
2002-08-30 01:14:33 +08:00
|
|
|
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
|
|
|
|
|
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-31 00:31:11 +08:00
|
|
|
lastrowid = fctx->lastrowid = pstrdup(values[0]);
|
2002-08-30 01:14:33 +08:00
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
}
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
if (!allnulls)
|
|
|
|
{
|
|
|
|
/* build the tuple */
|
|
|
|
tuple = BuildTupleFromCStrings(attinmeta, values);
|
|
|
|
|
|
|
|
/* make the tuple into a datum */
|
|
|
|
result = TupleGetDatum(slot, tuple);
|
|
|
|
|
|
|
|
/* Clean up */
|
|
|
|
for (i = 0; i < num_categories + 1; i++)
|
|
|
|
if (values[i] != NULL)
|
|
|
|
xpfree(values[i]);
|
|
|
|
xpfree(values);
|
|
|
|
|
2002-09-05 04:31:48 +08:00
|
|
|
SRF_RETURN_NEXT(funcctx, result);
|
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-31 00:31:11 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Skipping this tuple entirely, but we need to advance
|
2002-09-05 04:31:48 +08:00
|
|
|
* the counter like the API would if we had returned one.
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
call_cntr = ++funcctx->call_cntr;
|
|
|
|
|
|
|
|
/* we'll start over at the top */
|
|
|
|
xpfree(values);
|
|
|
|
|
|
|
|
/* see if we've gone too far already */
|
|
|
|
if (call_cntr >= max_calls)
|
|
|
|
{
|
|
|
|
/* release SPI related resources */
|
|
|
|
SPI_finish();
|
2002-09-05 04:31:48 +08:00
|
|
|
SRF_RETURN_DONE(funcctx);
|
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-31 00:31:11 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2002-09-05 04:31:48 +08:00
|
|
|
else
|
|
|
|
/* do when there is no more left */
|
|
|
|
{
|
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-31 00:31:11 +08:00
|
|
|
/* release SPI related resources */
|
|
|
|
SPI_finish();
|
2002-09-05 04:31:48 +08:00
|
|
|
SRF_RETURN_DONE(funcctx);
|
|
|
|
}
|
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-31 00:31:11 +08:00
|
|
|
}
|
|
|
|
|
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 14:46:30 +08:00
|
|
|
/*
|
|
|
|
* crosstab_hash - reimplement crosstab as materialized function and
|
|
|
|
* properly deal with missing values (i.e. don't pack remaining
|
|
|
|
* values to the left)
|
|
|
|
*
|
|
|
|
* crosstab - create a crosstab of rowids and values columns from a
|
|
|
|
* SQL statement returning one rowid column, one category column,
|
|
|
|
* and one value column.
|
|
|
|
*
|
|
|
|
* e.g. given sql which produces:
|
|
|
|
*
|
|
|
|
* rowid cat value
|
|
|
|
* ------+-------+-------
|
|
|
|
* row1 cat1 val1
|
|
|
|
* row1 cat2 val2
|
|
|
|
* row1 cat4 val4
|
|
|
|
* row2 cat1 val5
|
|
|
|
* row2 cat2 val6
|
|
|
|
* row2 cat3 val7
|
|
|
|
* row2 cat4 val8
|
|
|
|
*
|
|
|
|
* crosstab returns:
|
|
|
|
* <===== values columns =====>
|
|
|
|
* rowid cat1 cat2 cat3 cat4
|
|
|
|
* ------+-------+-------+-------+-------
|
|
|
|
* row1 val1 val2 null val4
|
|
|
|
* row2 val5 val6 val7 val8
|
|
|
|
*
|
|
|
|
* NOTES:
|
|
|
|
* 1. SQL result must be ordered by 1.
|
|
|
|
* 2. The number of values columns depends on the tuple description
|
|
|
|
* of the function's declared return type.
|
|
|
|
* 2. Missing values (i.e. missing category) are filled in with nulls.
|
|
|
|
* 3. Extra values (i.e. not in category results) are skipped.
|
|
|
|
*/
|
|
|
|
PG_FUNCTION_INFO_V1(crosstab_hash);
|
|
|
|
Datum
|
|
|
|
crosstab_hash(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
char *sql = GET_STR(PG_GETARG_TEXT_P(0));
|
|
|
|
char *cats_sql = GET_STR(PG_GETARG_TEXT_P(1));
|
|
|
|
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
MemoryContext per_query_ctx;
|
|
|
|
MemoryContext oldcontext;
|
|
|
|
int num_categories;
|
|
|
|
|
|
|
|
/* check to see if caller supports us returning a tuplestore */
|
|
|
|
if (!rsinfo || !(rsinfo->allowedModes & SFRM_Materialize))
|
|
|
|
elog(ERROR, "crosstab: materialize mode required, but it is not "
|
|
|
|
"allowed in this context");
|
|
|
|
|
|
|
|
per_query_ctx = rsinfo->econtext->ecxt_per_query_memory;
|
|
|
|
oldcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* get the requested return tuple description */
|
|
|
|
tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to make sure we have a reasonable tuple descriptor
|
|
|
|
*
|
|
|
|
* Note we will attempt to coerce the values into whatever
|
|
|
|
* the return attribute type is and depend on the "in"
|
|
|
|
* function to complain if needed.
|
|
|
|
*/
|
|
|
|
if (tupdesc->natts < 2)
|
|
|
|
elog(ERROR, "crosstab: query-specified return tuple and " \
|
|
|
|
"crosstab function are not compatible");
|
|
|
|
|
|
|
|
/* load up the categories hash table */
|
|
|
|
num_categories = load_categories_hash(cats_sql, per_query_ctx);
|
|
|
|
|
|
|
|
/* let the caller know we're sending back a tuplestore */
|
|
|
|
rsinfo->returnMode = SFRM_Materialize;
|
|
|
|
|
|
|
|
/* now go build it */
|
|
|
|
rsinfo->setResult = get_crosstab_tuplestore(sql,
|
|
|
|
num_categories,
|
|
|
|
tupdesc,
|
|
|
|
per_query_ctx);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SFRM_Materialize mode expects us to return a NULL Datum. The actual
|
|
|
|
* tuples are in our tuplestore and passed back through
|
|
|
|
* rsinfo->setResult. rsinfo->setDesc is set to the tuple description
|
|
|
|
* that we actually used to build our tuples with, so the caller can
|
|
|
|
* verify we did what it was expecting.
|
|
|
|
*/
|
|
|
|
rsinfo->setDesc = tupdesc;
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
return (Datum) 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* load up the categories hash table
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
load_categories_hash(char *cats_sql, MemoryContext per_query_ctx)
|
|
|
|
{
|
|
|
|
HASHCTL ctl;
|
|
|
|
int ret;
|
|
|
|
int proc;
|
|
|
|
MemoryContext SPIcontext;
|
|
|
|
int num_categories = 0;
|
|
|
|
|
|
|
|
/* initialize the category hash table */
|
|
|
|
ctl.keysize = MAX_CATNAME_LEN;
|
|
|
|
ctl.entrysize = sizeof(crosstab_HashEnt);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* use INIT_CATS, defined above as a guess of how
|
|
|
|
* many hash table entries to create, initially
|
|
|
|
*/
|
|
|
|
crosstab_HashTable = hash_create("crosstab hash", INIT_CATS, &ctl, HASH_ELEM);
|
|
|
|
|
|
|
|
/* Connect to SPI manager */
|
|
|
|
if ((ret = SPI_connect()) < 0)
|
|
|
|
elog(ERROR, "load_categories_hash: SPI_connect returned %d", ret);
|
|
|
|
|
|
|
|
/* Retrieve the category name rows */
|
|
|
|
ret = SPI_exec(cats_sql, 0);
|
|
|
|
num_categories = proc = SPI_processed;
|
|
|
|
|
|
|
|
/* Check for qualifying tuples */
|
|
|
|
if ((ret == SPI_OK_SELECT) && (proc > 0))
|
|
|
|
{
|
|
|
|
SPITupleTable *spi_tuptable = SPI_tuptable;
|
|
|
|
TupleDesc spi_tupdesc = spi_tuptable->tupdesc;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The provided categories SQL query must always return one column:
|
|
|
|
* category - the label or identifier for each column
|
|
|
|
*/
|
|
|
|
if (spi_tupdesc->natts != 1)
|
|
|
|
elog(ERROR, "load_categories_hash: provided categories SQL must " \
|
|
|
|
"return 1 column of at least one row");
|
|
|
|
|
|
|
|
for (i = 0; i < proc; i++)
|
|
|
|
{
|
|
|
|
crosstab_cat_desc *catdesc;
|
|
|
|
char *catname;
|
|
|
|
HeapTuple spi_tuple;
|
|
|
|
|
|
|
|
/* get the next sql result tuple */
|
|
|
|
spi_tuple = spi_tuptable->vals[i];
|
|
|
|
|
|
|
|
/* get the category from the current sql result tuple */
|
|
|
|
catname = SPI_getvalue(spi_tuple, spi_tupdesc, 1);
|
|
|
|
|
|
|
|
SPIcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
catdesc = (crosstab_cat_desc *) palloc(sizeof(crosstab_cat_desc));
|
|
|
|
catdesc->catname = catname;
|
|
|
|
catdesc->attidx = i;
|
|
|
|
|
|
|
|
/* Add the proc description block to the hashtable */
|
|
|
|
crosstab_HashTableInsert(catdesc);
|
|
|
|
|
|
|
|
MemoryContextSwitchTo(SPIcontext);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* no qualifying tuples */
|
|
|
|
SPI_finish();
|
|
|
|
elog(ERROR, "load_categories_hash: provided categories SQL must " \
|
|
|
|
"return 1 column of at least one row");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (SPI_finish() != SPI_OK_FINISH)
|
|
|
|
elog(ERROR, "load_categories_hash: SPI_finish() failed");
|
|
|
|
|
|
|
|
return num_categories;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* create and populate the crosstab tuplestore using the provided source query
|
|
|
|
*/
|
|
|
|
static Tuplestorestate *
|
|
|
|
get_crosstab_tuplestore(char *sql,
|
|
|
|
int num_categories,
|
|
|
|
TupleDesc tupdesc,
|
|
|
|
MemoryContext per_query_ctx)
|
|
|
|
{
|
|
|
|
Tuplestorestate *tupstore;
|
|
|
|
AttInMetadata *attinmeta = TupleDescGetAttInMetadata(tupdesc);
|
|
|
|
char **values;
|
|
|
|
HeapTuple tuple;
|
|
|
|
int ret;
|
|
|
|
int proc;
|
|
|
|
MemoryContext SPIcontext;
|
|
|
|
|
|
|
|
/* initialize our tuplestore */
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-28 00:51:29 +08:00
|
|
|
tupstore = tuplestore_begin_heap(true, false, SortMem);
|
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 14:46:30 +08:00
|
|
|
|
|
|
|
/* Connect to SPI manager */
|
|
|
|
if ((ret = SPI_connect()) < 0)
|
|
|
|
elog(ERROR, "get_crosstab_tuplestore: SPI_connect returned %d", ret);
|
|
|
|
|
|
|
|
/* Now retrieve the crosstab source rows */
|
|
|
|
ret = SPI_exec(sql, 0);
|
|
|
|
proc = SPI_processed;
|
|
|
|
|
|
|
|
/* Check for qualifying tuples */
|
|
|
|
if ((ret == SPI_OK_SELECT) && (proc > 0))
|
|
|
|
{
|
|
|
|
SPITupleTable *spi_tuptable = SPI_tuptable;
|
|
|
|
TupleDesc spi_tupdesc = spi_tuptable->tupdesc;
|
|
|
|
int ncols = spi_tupdesc->natts;
|
|
|
|
char *rowid;
|
|
|
|
char *lastrowid = NULL;
|
|
|
|
int i, j;
|
|
|
|
int result_ncols;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The provided SQL query must always return at least three columns:
|
|
|
|
*
|
|
|
|
* 1. rowname the label for each row - column 1 in the final result
|
|
|
|
* 2. category the label for each value-column in the final result
|
|
|
|
* 3. value the values used to populate the value-columns
|
|
|
|
*
|
|
|
|
* If there are more than three columns, the last two are taken as
|
|
|
|
* "category" and "values". The first column is taken as "rowname".
|
|
|
|
* Additional columns (2 thru N-2) are assumed the same for the same
|
|
|
|
* "rowname", and are copied into the result tuple from the first
|
|
|
|
* time we encounter a particular rowname.
|
|
|
|
*/
|
|
|
|
if (ncols < 3)
|
|
|
|
elog(ERROR, "get_crosstab_tuplestore: provided source SQL must " \
|
|
|
|
"return at least 3 columns; a rowid, a category, " \
|
|
|
|
"and a values column");
|
|
|
|
|
|
|
|
result_ncols = (ncols - 2) + num_categories;
|
|
|
|
|
|
|
|
/* Recheck to make sure we tuple descriptor still looks reasonable */
|
|
|
|
if (tupdesc->natts != result_ncols)
|
|
|
|
elog(ERROR, "get_crosstab_tuplestore: query-specified return " \
|
|
|
|
"tuple has %d columns but crosstab returns %d",
|
|
|
|
tupdesc->natts, result_ncols);
|
|
|
|
|
|
|
|
/* allocate space */
|
|
|
|
values = (char **) palloc(result_ncols * sizeof(char *));
|
|
|
|
|
|
|
|
/* and make sure it's clear */
|
|
|
|
memset(values, '\0', result_ncols * sizeof(char *));
|
|
|
|
|
|
|
|
for (i = 0; i < proc; i++)
|
|
|
|
{
|
|
|
|
HeapTuple spi_tuple;
|
|
|
|
crosstab_cat_desc *catdesc;
|
|
|
|
char *catname;
|
|
|
|
|
|
|
|
/* get the next sql result tuple */
|
|
|
|
spi_tuple = spi_tuptable->vals[i];
|
|
|
|
|
|
|
|
/* get the rowid from the current sql result tuple */
|
|
|
|
rowid = SPI_getvalue(spi_tuple, spi_tupdesc, 1);
|
|
|
|
|
|
|
|
/* if rowid is null, skip this tuple entirely */
|
|
|
|
if (rowid == NULL)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* if we're on a new output row, grab the column values up to
|
|
|
|
* column N-2 now
|
|
|
|
*/
|
|
|
|
if ((lastrowid == NULL) || (strcmp(rowid, lastrowid) != 0))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* a new row means we need to flush the old one first,
|
|
|
|
* unless we're on the very first row
|
|
|
|
*/
|
|
|
|
if (lastrowid != NULL)
|
|
|
|
{
|
|
|
|
/* switch to appropriate context while storing the tuple */
|
|
|
|
SPIcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* rowid changed, flush the previous output row */
|
|
|
|
tuple = BuildTupleFromCStrings(attinmeta, values);
|
|
|
|
tuplestore_puttuple(tupstore, tuple);
|
|
|
|
for (j = 0; j < result_ncols; j++)
|
|
|
|
xpfree(values[j]);
|
|
|
|
|
|
|
|
/* now reset the context */
|
|
|
|
MemoryContextSwitchTo(SPIcontext);
|
|
|
|
}
|
|
|
|
|
|
|
|
values[0] = rowid;
|
|
|
|
for (j = 1; j < ncols - 2; j++)
|
|
|
|
values[j] = SPI_getvalue(spi_tuple, spi_tupdesc, j + 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* look up the category and fill in the appropriate column */
|
|
|
|
catname = SPI_getvalue(spi_tuple, spi_tupdesc, ncols - 1);
|
|
|
|
|
|
|
|
if (catname != NULL)
|
|
|
|
{
|
|
|
|
crosstab_HashTableLookup(catname, catdesc);
|
|
|
|
|
|
|
|
if (catdesc)
|
|
|
|
values[catdesc->attidx + ncols - 2] =
|
|
|
|
SPI_getvalue(spi_tuple, spi_tupdesc, ncols);
|
|
|
|
}
|
|
|
|
|
|
|
|
xpfree(lastrowid);
|
|
|
|
lastrowid = pstrdup(rowid);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* switch to appropriate context while storing the tuple */
|
|
|
|
SPIcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* flush the last output row */
|
|
|
|
tuple = BuildTupleFromCStrings(attinmeta, values);
|
|
|
|
tuplestore_puttuple(tupstore, tuple);
|
|
|
|
|
|
|
|
/* now reset the context */
|
|
|
|
MemoryContextSwitchTo(SPIcontext);
|
|
|
|
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* no qualifying tuples */
|
|
|
|
SPI_finish();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (SPI_finish() != SPI_OK_FINISH)
|
|
|
|
elog(ERROR, "get_crosstab_tuplestore: SPI_finish() failed");
|
|
|
|
|
|
|
|
tuplestore_donestoring(tupstore);
|
|
|
|
|
|
|
|
return tupstore;
|
|
|
|
}
|
|
|
|
|
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 13:44:05 +08:00
|
|
|
/*
|
|
|
|
* connectby_text - produce a result set from a hierarchical (parent/child)
|
|
|
|
* table.
|
|
|
|
*
|
|
|
|
* e.g. given table foo:
|
|
|
|
*
|
|
|
|
* keyid parent_keyid
|
|
|
|
* ------+--------------
|
2002-09-05 04:31:48 +08:00
|
|
|
* row1 NULL
|
|
|
|
* row2 row1
|
|
|
|
* row3 row1
|
|
|
|
* row4 row2
|
|
|
|
* row5 row2
|
|
|
|
* row6 row4
|
|
|
|
* row7 row3
|
|
|
|
* row8 row6
|
|
|
|
* row9 row5
|
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 13:44:05 +08:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* connectby(text relname, text keyid_fld, text parent_keyid_fld,
|
2002-09-05 04:31:48 +08:00
|
|
|
* text start_with, int max_depth [, text branch_delim])
|
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 13:44:05 +08:00
|
|
|
* connectby('foo', 'keyid', 'parent_keyid', 'row2', 0, '~') returns:
|
|
|
|
*
|
|
|
|
* keyid parent_id level branch
|
|
|
|
* ------+-----------+--------+-----------------------
|
2002-09-05 04:31:48 +08:00
|
|
|
* row2 NULL 0 row2
|
|
|
|
* row4 row2 1 row2~row4
|
|
|
|
* row6 row4 2 row2~row4~row6
|
|
|
|
* row8 row6 3 row2~row4~row6~row8
|
|
|
|
* row5 row2 1 row2~row5
|
|
|
|
* row9 row5 2 row2~row5~row9
|
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 13:44:05 +08:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
PG_FUNCTION_INFO_V1(connectby_text);
|
|
|
|
|
|
|
|
#define CONNECTBY_NCOLS 4
|
|
|
|
#define CONNECTBY_NCOLS_NOBRANCH 3
|
|
|
|
|
|
|
|
Datum
|
|
|
|
connectby_text(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
char *relname = GET_STR(PG_GETARG_TEXT_P(0));
|
|
|
|
char *key_fld = GET_STR(PG_GETARG_TEXT_P(1));
|
|
|
|
char *parent_key_fld = GET_STR(PG_GETARG_TEXT_P(2));
|
|
|
|
char *start_with = GET_STR(PG_GETARG_TEXT_P(3));
|
|
|
|
int max_depth = PG_GETARG_INT32(4);
|
|
|
|
char *branch_delim = NULL;
|
|
|
|
bool show_branch = false;
|
|
|
|
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
AttInMetadata *attinmeta;
|
|
|
|
MemoryContext per_query_ctx;
|
|
|
|
MemoryContext oldcontext;
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
if (fcinfo->nargs == 6)
|
|
|
|
{
|
|
|
|
branch_delim = GET_STR(PG_GETARG_TEXT_P(5));
|
|
|
|
show_branch = true;
|
|
|
|
}
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
else
|
|
|
|
/* default is no show, tilde for the delimiter */
|
|
|
|
branch_delim = pstrdup("~");
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
per_query_ctx = rsinfo->econtext->ecxt_per_query_memory;
|
|
|
|
oldcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* get the requested return tuple description */
|
|
|
|
tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);
|
|
|
|
|
|
|
|
/* does it meet our needs */
|
|
|
|
validateConnectbyTupleDesc(tupdesc, show_branch);
|
|
|
|
|
|
|
|
/* OK, use it then */
|
|
|
|
attinmeta = TupleDescGetAttInMetadata(tupdesc);
|
|
|
|
|
|
|
|
/* check to see if caller supports us returning a tuplestore */
|
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 14:46:30 +08:00
|
|
|
if (!rsinfo || !(rsinfo->allowedModes & SFRM_Materialize))
|
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 13:44:05 +08:00
|
|
|
elog(ERROR, "connectby requires Materialize mode, but it is not "
|
2002-09-05 04:31:48 +08:00
|
|
|
"allowed in this context");
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* OK, go to work */
|
|
|
|
rsinfo->returnMode = SFRM_Materialize;
|
|
|
|
rsinfo->setResult = connectby(relname,
|
|
|
|
key_fld,
|
|
|
|
parent_key_fld,
|
|
|
|
branch_delim,
|
|
|
|
start_with,
|
|
|
|
max_depth,
|
|
|
|
show_branch,
|
|
|
|
per_query_ctx,
|
|
|
|
attinmeta);
|
|
|
|
rsinfo->setDesc = tupdesc;
|
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* SFRM_Materialize mode expects us to return a NULL Datum. The actual
|
|
|
|
* tuples are in our tuplestore and passed back through
|
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 13:44:05 +08:00
|
|
|
* rsinfo->setResult. rsinfo->setDesc is set to the tuple description
|
|
|
|
* that we actually used to build our tuples with, so the caller can
|
|
|
|
* verify we did what it was expecting.
|
|
|
|
*/
|
|
|
|
return (Datum) 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* connectby - does the real work for connectby_text()
|
|
|
|
*/
|
|
|
|
static Tuplestorestate *
|
|
|
|
connectby(char *relname,
|
|
|
|
char *key_fld,
|
|
|
|
char *parent_key_fld,
|
|
|
|
char *branch_delim,
|
|
|
|
char *start_with,
|
|
|
|
int max_depth,
|
|
|
|
bool show_branch,
|
|
|
|
MemoryContext per_query_ctx,
|
|
|
|
AttInMetadata *attinmeta)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
Tuplestorestate *tupstore = NULL;
|
|
|
|
int ret;
|
|
|
|
MemoryContext oldcontext;
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* Connect to SPI manager */
|
|
|
|
if ((ret = SPI_connect()) < 0)
|
|
|
|
elog(ERROR, "connectby: SPI_connect returned %d", ret);
|
|
|
|
|
|
|
|
/* switch to longer term context to create the tuple store */
|
|
|
|
oldcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* initialize our tuplestore */
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-28 00:51:29 +08:00
|
|
|
tupstore = tuplestore_begin_heap(true, false, SortMem);
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
/* now go get the whole tree */
|
|
|
|
tupstore = build_tuplestore_recursively(key_fld,
|
2002-09-05 04:31:48 +08:00
|
|
|
parent_key_fld,
|
|
|
|
relname,
|
|
|
|
branch_delim,
|
|
|
|
start_with,
|
|
|
|
start_with, /* current_branch */
|
|
|
|
0, /* initial level is 0 */
|
|
|
|
max_depth,
|
|
|
|
show_branch,
|
|
|
|
per_query_ctx,
|
|
|
|
attinmeta,
|
|
|
|
tupstore);
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
SPI_finish();
|
|
|
|
|
|
|
|
return tupstore;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Tuplestorestate *
|
|
|
|
build_tuplestore_recursively(char *key_fld,
|
|
|
|
char *parent_key_fld,
|
|
|
|
char *relname,
|
|
|
|
char *branch_delim,
|
|
|
|
char *start_with,
|
|
|
|
char *branch,
|
|
|
|
int level,
|
|
|
|
int max_depth,
|
|
|
|
bool show_branch,
|
|
|
|
MemoryContext per_query_ctx,
|
|
|
|
AttInMetadata *attinmeta,
|
|
|
|
Tuplestorestate *tupstore)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
TupleDesc tupdesc = attinmeta->tupdesc;
|
|
|
|
MemoryContext oldcontext;
|
|
|
|
StringInfo sql = makeStringInfo();
|
|
|
|
int ret;
|
|
|
|
int proc;
|
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 13:44:05 +08:00
|
|
|
|
2002-09-05 04:31:48 +08:00
|
|
|
if (max_depth > 0 && level > max_depth)
|
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 13:44:05 +08:00
|
|
|
return tupstore;
|
|
|
|
|
|
|
|
/* Build initial sql statement */
|
|
|
|
appendStringInfo(sql, "SELECT %s, %s FROM %s WHERE %s = '%s' AND %s IS NOT NULL",
|
2002-11-23 09:54:09 +08:00
|
|
|
key_fld,
|
|
|
|
parent_key_fld,
|
|
|
|
relname,
|
|
|
|
parent_key_fld,
|
2002-09-05 04:31:48 +08:00
|
|
|
start_with,
|
2002-11-23 09:54:09 +08:00
|
|
|
key_fld);
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* Retrieve the desired rows */
|
|
|
|
ret = SPI_exec(sql->data, 0);
|
|
|
|
proc = SPI_processed;
|
|
|
|
|
|
|
|
/* Check for qualifying tuples */
|
|
|
|
if ((ret == SPI_OK_SELECT) && (proc > 0))
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
HeapTuple tuple;
|
|
|
|
HeapTuple spi_tuple;
|
|
|
|
SPITupleTable *tuptable = SPI_tuptable;
|
|
|
|
TupleDesc spi_tupdesc = tuptable->tupdesc;
|
|
|
|
int i;
|
|
|
|
char *current_key;
|
|
|
|
char *current_key_parent;
|
|
|
|
char current_level[INT32_STRLEN];
|
|
|
|
char *current_branch;
|
|
|
|
char **values;
|
> Now I'm testing connectby() in the /contrib/tablefunc in 7.3b1, which would
> be a useful function for many users. However, I found the fact that
> if connectby_tree has the following data, connectby() tries to search the end
> of roots without knowing that the relations are infinite(-5-9-10-11-9-10-11-)
.
> I hope connectby() supports a check routine to find infinite relations.
>
>
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
> INSERT INTO connectby_tree VALUES(1,NULL);
> INSERT INTO connectby_tree VALUES(2,1);
> INSERT INTO connectby_tree VALUES(3,1);
> INSERT INTO connectby_tree VALUES(4,2);
> INSERT INTO connectby_tree VALUES(5,2);
> INSERT INTO connectby_tree VALUES(6,4);
> INSERT INTO connectby_tree VALUES(7,3);
> INSERT INTO connectby_tree VALUES(8,6);
> INSERT INTO connectby_tree VALUES(9,5);
>
> INSERT INTO connectby_tree VALUES(10,9);
> INSERT INTO connectby_tree VALUES(11,10);
> INSERT INTO connectby_tree VALUES(9,11); <-- infinite
>
The attached patch fixes the infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby found by Masaru Sugawara.
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 4, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+-------------
2 | | 0 | 2
4 | 2 | 1 | 2~4
6 | 4 | 2 | 2~4~6
8 | 6 | 3 | 2~4~6~8
5 | 2 | 1 | 2~5
9 | 5 | 2 | 2~5~9
10 | 9 | 3 | 2~5~9~10
11 | 10 | 4 | 2~5~9~10~11
(8 rows)
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 5, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
ERROR: infinite recursion detected
I implemented it by checking the branch string for repeated keys
(whether or not the branch is returned). The performance hit was pretty
minimal -- about 1% for a moderately complex test case (220000 record
table, 9 level tree with 3800 members).
Joe Conway
2002-09-12 08:19:44 +08:00
|
|
|
StringInfo branchstr = NULL;
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
StringInfo chk_branchstr = NULL;
|
|
|
|
StringInfo chk_current_key = NULL;
|
> Now I'm testing connectby() in the /contrib/tablefunc in 7.3b1, which would
> be a useful function for many users. However, I found the fact that
> if connectby_tree has the following data, connectby() tries to search the end
> of roots without knowing that the relations are infinite(-5-9-10-11-9-10-11-)
.
> I hope connectby() supports a check routine to find infinite relations.
>
>
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
> INSERT INTO connectby_tree VALUES(1,NULL);
> INSERT INTO connectby_tree VALUES(2,1);
> INSERT INTO connectby_tree VALUES(3,1);
> INSERT INTO connectby_tree VALUES(4,2);
> INSERT INTO connectby_tree VALUES(5,2);
> INSERT INTO connectby_tree VALUES(6,4);
> INSERT INTO connectby_tree VALUES(7,3);
> INSERT INTO connectby_tree VALUES(8,6);
> INSERT INTO connectby_tree VALUES(9,5);
>
> INSERT INTO connectby_tree VALUES(10,9);
> INSERT INTO connectby_tree VALUES(11,10);
> INSERT INTO connectby_tree VALUES(9,11); <-- infinite
>
The attached patch fixes the infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby found by Masaru Sugawara.
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 4, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+-------------
2 | | 0 | 2
4 | 2 | 1 | 2~4
6 | 4 | 2 | 2~4~6
8 | 6 | 3 | 2~4~6~8
5 | 2 | 1 | 2~5
9 | 5 | 2 | 2~5~9
10 | 9 | 3 | 2~5~9~10
11 | 10 | 4 | 2~5~9~10~11
(8 rows)
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 5, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
ERROR: infinite recursion detected
I implemented it by checking the branch string for repeated keys
(whether or not the branch is returned). The performance hit was pretty
minimal -- about 1% for a moderately complex test case (220000 record
table, 9 level tree with 3800 members).
Joe Conway
2002-09-12 08:19:44 +08:00
|
|
|
|
|
|
|
/* start a new branch */
|
|
|
|
branchstr = makeStringInfo();
|
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 13:44:05 +08:00
|
|
|
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
/* need these to check for recursion */
|
|
|
|
chk_branchstr = makeStringInfo();
|
|
|
|
chk_current_key = makeStringInfo();
|
|
|
|
|
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 13:44:05 +08:00
|
|
|
if (show_branch)
|
|
|
|
values = (char **) palloc(CONNECTBY_NCOLS * sizeof(char *));
|
|
|
|
else
|
|
|
|
values = (char **) palloc(CONNECTBY_NCOLS_NOBRANCH * sizeof(char *));
|
|
|
|
|
|
|
|
/* First time through, do a little setup */
|
|
|
|
if (level == 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Check that return tupdesc is compatible with the one we got
|
2002-09-05 04:31:48 +08:00
|
|
|
* from the query, but only at level 0 -- no need to check
|
|
|
|
* more than once
|
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 13:44:05 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
if (!compatConnectbyTupleDescs(tupdesc, spi_tupdesc))
|
|
|
|
elog(ERROR, "connectby: return and sql tuple descriptions are "
|
2002-09-05 04:31:48 +08:00
|
|
|
"incompatible");
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* root value is the one we initially start with */
|
|
|
|
values[0] = start_with;
|
|
|
|
|
|
|
|
/* root value has no parent */
|
|
|
|
values[1] = NULL;
|
|
|
|
|
|
|
|
/* root level is 0 */
|
|
|
|
sprintf(current_level, "%d", level);
|
|
|
|
values[2] = current_level;
|
|
|
|
|
|
|
|
/* root branch is just starting root value */
|
|
|
|
if (show_branch)
|
|
|
|
values[3] = start_with;
|
|
|
|
|
|
|
|
/* construct the tuple */
|
|
|
|
tuple = BuildTupleFromCStrings(attinmeta, values);
|
|
|
|
|
|
|
|
/* switch to long lived context while storing the tuple */
|
|
|
|
oldcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* now store it */
|
|
|
|
tuplestore_puttuple(tupstore, tuple);
|
|
|
|
|
|
|
|
/* now reset the context */
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
/* increment level */
|
|
|
|
level++;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < proc; i++)
|
|
|
|
{
|
> Now I'm testing connectby() in the /contrib/tablefunc in 7.3b1, which would
> be a useful function for many users. However, I found the fact that
> if connectby_tree has the following data, connectby() tries to search the end
> of roots without knowing that the relations are infinite(-5-9-10-11-9-10-11-)
.
> I hope connectby() supports a check routine to find infinite relations.
>
>
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
> INSERT INTO connectby_tree VALUES(1,NULL);
> INSERT INTO connectby_tree VALUES(2,1);
> INSERT INTO connectby_tree VALUES(3,1);
> INSERT INTO connectby_tree VALUES(4,2);
> INSERT INTO connectby_tree VALUES(5,2);
> INSERT INTO connectby_tree VALUES(6,4);
> INSERT INTO connectby_tree VALUES(7,3);
> INSERT INTO connectby_tree VALUES(8,6);
> INSERT INTO connectby_tree VALUES(9,5);
>
> INSERT INTO connectby_tree VALUES(10,9);
> INSERT INTO connectby_tree VALUES(11,10);
> INSERT INTO connectby_tree VALUES(9,11); <-- infinite
>
The attached patch fixes the infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby found by Masaru Sugawara.
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 4, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+-------------
2 | | 0 | 2
4 | 2 | 1 | 2~4
6 | 4 | 2 | 2~4~6
8 | 6 | 3 | 2~4~6~8
5 | 2 | 1 | 2~5
9 | 5 | 2 | 2~5~9
10 | 9 | 3 | 2~5~9~10
11 | 10 | 4 | 2~5~9~10~11
(8 rows)
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 5, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
ERROR: infinite recursion detected
I implemented it by checking the branch string for repeated keys
(whether or not the branch is returned). The performance hit was pretty
minimal -- about 1% for a moderately complex test case (220000 record
table, 9 level tree with 3800 members).
Joe Conway
2002-09-12 08:19:44 +08:00
|
|
|
/* initialize branch for this pass */
|
|
|
|
appendStringInfo(branchstr, "%s", branch);
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
appendStringInfo(chk_branchstr, "%s%s%s", branch_delim, branch, branch_delim);
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* get the next sql result tuple */
|
|
|
|
spi_tuple = tuptable->vals[i];
|
|
|
|
|
|
|
|
/* get the current key and parent */
|
|
|
|
current_key = SPI_getvalue(spi_tuple, spi_tupdesc, 1);
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
appendStringInfo(chk_current_key, "%s%s%s", branch_delim, current_key, branch_delim);
|
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 13:44:05 +08:00
|
|
|
current_key_parent = pstrdup(SPI_getvalue(spi_tuple, spi_tupdesc, 2));
|
|
|
|
|
|
|
|
/* get the current level */
|
|
|
|
sprintf(current_level, "%d", level);
|
|
|
|
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
/* check to see if this key is also an ancestor */
|
|
|
|
if (strstr(chk_branchstr->data, chk_current_key->data))
|
|
|
|
elog(ERROR, "infinite recursion detected");
|
|
|
|
|
|
|
|
/* OK, extend the branch */
|
> Now I'm testing connectby() in the /contrib/tablefunc in 7.3b1, which would
> be a useful function for many users. However, I found the fact that
> if connectby_tree has the following data, connectby() tries to search the end
> of roots without knowing that the relations are infinite(-5-9-10-11-9-10-11-)
.
> I hope connectby() supports a check routine to find infinite relations.
>
>
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
> INSERT INTO connectby_tree VALUES(1,NULL);
> INSERT INTO connectby_tree VALUES(2,1);
> INSERT INTO connectby_tree VALUES(3,1);
> INSERT INTO connectby_tree VALUES(4,2);
> INSERT INTO connectby_tree VALUES(5,2);
> INSERT INTO connectby_tree VALUES(6,4);
> INSERT INTO connectby_tree VALUES(7,3);
> INSERT INTO connectby_tree VALUES(8,6);
> INSERT INTO connectby_tree VALUES(9,5);
>
> INSERT INTO connectby_tree VALUES(10,9);
> INSERT INTO connectby_tree VALUES(11,10);
> INSERT INTO connectby_tree VALUES(9,11); <-- infinite
>
The attached patch fixes the infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby found by Masaru Sugawara.
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 4, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+-------------
2 | | 0 | 2
4 | 2 | 1 | 2~4
6 | 4 | 2 | 2~4~6
8 | 6 | 3 | 2~4~6~8
5 | 2 | 1 | 2~5
9 | 5 | 2 | 2~5~9
10 | 9 | 3 | 2~5~9~10
11 | 10 | 4 | 2~5~9~10~11
(8 rows)
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 5, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
ERROR: infinite recursion detected
I implemented it by checking the branch string for repeated keys
(whether or not the branch is returned). The performance hit was pretty
minimal -- about 1% for a moderately complex test case (220000 record
table, 9 level tree with 3800 members).
Joe Conway
2002-09-12 08:19:44 +08:00
|
|
|
appendStringInfo(branchstr, "%s%s", branch_delim, current_key);
|
|
|
|
current_branch = branchstr->data;
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* build a tuple */
|
|
|
|
values[0] = pstrdup(current_key);
|
|
|
|
values[1] = current_key_parent;
|
|
|
|
values[2] = current_level;
|
|
|
|
if (show_branch)
|
|
|
|
values[3] = current_branch;
|
|
|
|
|
|
|
|
tuple = BuildTupleFromCStrings(attinmeta, values);
|
|
|
|
|
|
|
|
xpfree(current_key);
|
|
|
|
xpfree(current_key_parent);
|
|
|
|
|
|
|
|
/* switch to long lived context while storing the tuple */
|
|
|
|
oldcontext = MemoryContextSwitchTo(per_query_ctx);
|
|
|
|
|
|
|
|
/* store the tuple for later use */
|
|
|
|
tuplestore_puttuple(tupstore, tuple);
|
|
|
|
|
|
|
|
/* now reset the context */
|
|
|
|
MemoryContextSwitchTo(oldcontext);
|
|
|
|
|
|
|
|
heap_freetuple(tuple);
|
|
|
|
|
|
|
|
/* recurse using current_key_parent as the new start_with */
|
|
|
|
tupstore = build_tuplestore_recursively(key_fld,
|
2002-09-05 04:31:48 +08:00
|
|
|
parent_key_fld,
|
|
|
|
relname,
|
|
|
|
branch_delim,
|
|
|
|
values[0],
|
|
|
|
current_branch,
|
|
|
|
level + 1,
|
|
|
|
max_depth,
|
|
|
|
show_branch,
|
|
|
|
per_query_ctx,
|
|
|
|
attinmeta,
|
|
|
|
tupstore);
|
> Now I'm testing connectby() in the /contrib/tablefunc in 7.3b1, which would
> be a useful function for many users. However, I found the fact that
> if connectby_tree has the following data, connectby() tries to search the end
> of roots without knowing that the relations are infinite(-5-9-10-11-9-10-11-)
.
> I hope connectby() supports a check routine to find infinite relations.
>
>
> CREATE TABLE connectby_tree(keyid int, parent_keyid int);
> INSERT INTO connectby_tree VALUES(1,NULL);
> INSERT INTO connectby_tree VALUES(2,1);
> INSERT INTO connectby_tree VALUES(3,1);
> INSERT INTO connectby_tree VALUES(4,2);
> INSERT INTO connectby_tree VALUES(5,2);
> INSERT INTO connectby_tree VALUES(6,4);
> INSERT INTO connectby_tree VALUES(7,3);
> INSERT INTO connectby_tree VALUES(8,6);
> INSERT INTO connectby_tree VALUES(9,5);
>
> INSERT INTO connectby_tree VALUES(10,9);
> INSERT INTO connectby_tree VALUES(11,10);
> INSERT INTO connectby_tree VALUES(9,11); <-- infinite
>
The attached patch fixes the infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby found by Masaru Sugawara.
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 4, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+-------------
2 | | 0 | 2
4 | 2 | 1 | 2~4
6 | 4 | 2 | 2~4~6
8 | 6 | 3 | 2~4~6~8
5 | 2 | 1 | 2~5
9 | 5 | 2 | 2~5~9
10 | 9 | 3 | 2~5~9~10
11 | 10 | 4 | 2~5~9~10~11
(8 rows)
test=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '2', 5, '~') AS t(keyid int, parent_keyid int, level
int, branch text);
ERROR: infinite recursion detected
I implemented it by checking the branch string for repeated keys
(whether or not the branch is returned). The performance hit was pretty
minimal -- about 1% for a moderately complex test case (220000 record
table, 9 level tree with 3800 members).
Joe Conway
2002-09-12 08:19:44 +08:00
|
|
|
|
|
|
|
/* reset branch for next pass */
|
|
|
|
xpfree(branchstr->data);
|
|
|
|
initStringInfo(branchstr);
|
> The previous patch fixed an infinite recursion bug in
> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
> if (strstr(branch_delim || branchstr->data || branch_delim,
> branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.
Good point. Thank you Masaru for the suggested fix.
Attached is a patch to fix the bug found by Masaru. His example now
produces:
regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
keyid | parent_keyid | level | branch
-------+--------------+-------+----------
11 | | 0 | 11
10 | 11 | 1 | 11-10
111 | 11 | 1 | 11-111
1 | 111 | 2 | 11-111-1
(4 rows)
While making the patch I also realized that the "no show branch" form of
the function was not going to work very well for recursion detection.
Therefore there is now a default branch delimiter ('~') that is used
internally, for that case, to enable recursion detection to work. If
you need a different delimiter for your specific data, you will have to
use the "show branch" form of the function.
Joe Conway
2002-10-04 01:11:12 +08:00
|
|
|
|
|
|
|
xpfree(chk_branchstr->data);
|
|
|
|
initStringInfo(chk_branchstr);
|
|
|
|
|
|
|
|
xpfree(chk_current_key->data);
|
|
|
|
initStringInfo(chk_current_key);
|
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 13:44:05 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return tupstore;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check expected (query runtime) tupdesc suitable for Connectby
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
validateConnectbyTupleDesc(TupleDesc tupdesc, bool show_branch)
|
|
|
|
{
|
|
|
|
/* are there the correct number of columns */
|
|
|
|
if (show_branch)
|
|
|
|
{
|
|
|
|
if (tupdesc->natts != CONNECTBY_NCOLS)
|
|
|
|
elog(ERROR, "Query-specified return tuple not valid for Connectby: "
|
2002-09-05 04:31:48 +08:00
|
|
|
"wrong number of columns");
|
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 13:44:05 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (tupdesc->natts != CONNECTBY_NCOLS_NOBRANCH)
|
|
|
|
elog(ERROR, "Query-specified return tuple not valid for Connectby: "
|
2002-09-05 04:31:48 +08:00
|
|
|
"wrong number of columns");
|
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 13:44:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* check that the types of the first two columns match */
|
|
|
|
if (tupdesc->attrs[0]->atttypid != tupdesc->attrs[1]->atttypid)
|
|
|
|
elog(ERROR, "Query-specified return tuple not valid for Connectby: "
|
2002-09-05 04:31:48 +08:00
|
|
|
"first two columns must be the same type");
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* check that the type of the third column is INT4 */
|
|
|
|
if (tupdesc->attrs[2]->atttypid != INT4OID)
|
|
|
|
elog(ERROR, "Query-specified return tuple not valid for Connectby: "
|
2002-09-05 04:31:48 +08:00
|
|
|
"third column must be type %s", format_type_be(INT4OID));
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* check that the type of the forth column is TEXT if applicable */
|
|
|
|
if (show_branch && tupdesc->attrs[3]->atttypid != TEXTOID)
|
|
|
|
elog(ERROR, "Query-specified return tuple not valid for Connectby: "
|
2002-09-05 04:31:48 +08:00
|
|
|
"third column must be type %s", format_type_be(TEXTOID));
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* OK, the tupdesc is valid for our purposes */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if spi sql tupdesc and return tupdesc are compatible
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
compatConnectbyTupleDescs(TupleDesc ret_tupdesc, TupleDesc sql_tupdesc)
|
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
Oid ret_atttypid;
|
|
|
|
Oid sql_atttypid;
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* check the key_fld types match */
|
|
|
|
ret_atttypid = ret_tupdesc->attrs[0]->atttypid;
|
|
|
|
sql_atttypid = sql_tupdesc->attrs[0]->atttypid;
|
|
|
|
if (ret_atttypid != sql_atttypid)
|
|
|
|
elog(ERROR, "compatConnectbyTupleDescs: SQL key field datatype does "
|
2002-09-05 04:31:48 +08:00
|
|
|
"not match return key field datatype");
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* check the parent_key_fld types match */
|
|
|
|
ret_atttypid = ret_tupdesc->attrs[1]->atttypid;
|
|
|
|
sql_atttypid = sql_tupdesc->attrs[1]->atttypid;
|
|
|
|
if (ret_atttypid != sql_atttypid)
|
|
|
|
elog(ERROR, "compatConnectbyTupleDescs: SQL parent key field datatype "
|
2002-09-05 04:31:48 +08:00
|
|
|
"does not match return parent key field datatype");
|
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 13:44:05 +08:00
|
|
|
|
|
|
|
/* OK, the two tupdescs are compatible for our purposes */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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-31 00:31:11 +08:00
|
|
|
/*
|
|
|
|
* Check if two tupdescs match in type of attributes
|
|
|
|
*/
|
|
|
|
static bool
|
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 13:44:05 +08:00
|
|
|
compatCrosstabTupleDescs(TupleDesc ret_tupdesc, TupleDesc sql_tupdesc)
|
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-31 00:31:11 +08:00
|
|
|
{
|
|
|
|
int i;
|
2002-09-05 04:31:48 +08:00
|
|
|
Form_pg_attribute ret_attr;
|
|
|
|
Oid ret_atttypid;
|
|
|
|
Form_pg_attribute sql_attr;
|
|
|
|
Oid sql_atttypid;
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/* check the rowid types match */
|
|
|
|
ret_atttypid = ret_tupdesc->attrs[0]->atttypid;
|
|
|
|
sql_atttypid = sql_tupdesc->attrs[0]->atttypid;
|
|
|
|
if (ret_atttypid != sql_atttypid)
|
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 13:44:05 +08:00
|
|
|
elog(ERROR, "compatCrosstabTupleDescs: SQL rowid datatype does not match"
|
2002-09-05 04:31:48 +08:00
|
|
|
" return rowid datatype");
|
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-31 00:31:11 +08:00
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* - attribute [1] of the sql tuple is the category; no need to check
|
|
|
|
* it - attribute [2] of the sql tuple should match attributes [1] to
|
|
|
|
* [natts] of the return tuple
|
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-31 00:31:11 +08:00
|
|
|
*/
|
|
|
|
sql_attr = sql_tupdesc->attrs[2];
|
|
|
|
for (i = 1; i < ret_tupdesc->natts; i++)
|
|
|
|
{
|
|
|
|
ret_attr = ret_tupdesc->attrs[i];
|
|
|
|
|
|
|
|
if (ret_attr->atttypid != sql_attr->atttypid)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* OK, the two tupdescs are compatible for our purposes */
|
|
|
|
return true;
|
|
|
|
}
|
2002-08-15 10:51:27 +08:00
|
|
|
|
|
|
|
static TupleDesc
|
2003-03-11 06:28:22 +08:00
|
|
|
make_crosstab_tupledesc(TupleDesc spi_tupdesc, int num_categories)
|
2002-08-15 10:51:27 +08:00
|
|
|
{
|
2002-09-05 04:31:48 +08:00
|
|
|
Form_pg_attribute sql_attr;
|
|
|
|
Oid sql_atttypid;
|
|
|
|
TupleDesc tupdesc;
|
|
|
|
int natts;
|
|
|
|
AttrNumber attnum;
|
|
|
|
char attname[NAMEDATALEN];
|
|
|
|
int i;
|
2002-08-15 10:51:27 +08:00
|
|
|
|
|
|
|
/*
|
2002-09-05 04:31:48 +08:00
|
|
|
* We need to build a tuple description with one column for the
|
2003-03-11 06:28:22 +08:00
|
|
|
* rowname, and num_categories columns for the values. Each must be of
|
2002-09-05 04:31:48 +08:00
|
|
|
* the same type as the corresponding spi result input column.
|
2002-08-15 10:51:27 +08:00
|
|
|
*/
|
2003-03-11 06:28:22 +08:00
|
|
|
natts = num_categories + 1;
|
2002-09-02 09:05:06 +08:00
|
|
|
tupdesc = CreateTemplateTupleDesc(natts, false);
|
2002-08-15 10:51:27 +08:00
|
|
|
|
|
|
|
/* first the rowname column */
|
|
|
|
attnum = 1;
|
|
|
|
|
|
|
|
sql_attr = spi_tupdesc->attrs[0];
|
|
|
|
sql_atttypid = sql_attr->atttypid;
|
|
|
|
|
|
|
|
strcpy(attname, "rowname");
|
|
|
|
|
|
|
|
TupleDescInitEntry(tupdesc, attnum, attname, sql_atttypid,
|
|
|
|
-1, 0, false);
|
|
|
|
|
2003-03-11 06:28:22 +08:00
|
|
|
/* now the category values columns */
|
2002-08-15 10:51:27 +08:00
|
|
|
sql_attr = spi_tupdesc->attrs[2];
|
|
|
|
sql_atttypid = sql_attr->atttypid;
|
|
|
|
|
2003-03-11 06:28:22 +08:00
|
|
|
for (i = 0; i < num_categories; i++)
|
2002-08-15 10:51:27 +08:00
|
|
|
{
|
|
|
|
attnum++;
|
|
|
|
|
|
|
|
sprintf(attname, "category_%d", i + 1);
|
|
|
|
TupleDescInitEntry(tupdesc, attnum, attname, sql_atttypid,
|
|
|
|
-1, 0, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
return tupdesc;
|
|
|
|
}
|