2016-06-10 04:44:25 +08:00
|
|
|
/* contrib/btree_gist/btree_gist--1.2.sql */
|
2002-07-31 01:34:37 +08:00
|
|
|
|
2011-10-13 03:45:03 +08:00
|
|
|
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
|
|
|
|
\echo Use "CREATE EXTENSION btree_gist" to load this file. \quit
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey4_in(cstring)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey4
|
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_in'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey4_out(gbtreekey4)
|
2003-03-21 02:59:18 +08:00
|
|
|
RETURNS cstring
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_out'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
CREATE TYPE gbtreekey4 (
|
2007-11-11 11:25:35 +08:00
|
|
|
INTERNALLENGTH = 4,
|
|
|
|
INPUT = gbtreekey4_in,
|
|
|
|
OUTPUT = gbtreekey4_out
|
2003-03-21 02:59:18 +08:00
|
|
|
);
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey8_in(cstring)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey8
|
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_in'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey8_out(gbtreekey8)
|
2002-08-22 08:01:51 +08:00
|
|
|
RETURNS cstring
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_out'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
CREATE TYPE gbtreekey8 (
|
2007-11-11 11:25:35 +08:00
|
|
|
INTERNALLENGTH = 8,
|
|
|
|
INPUT = gbtreekey8_in,
|
|
|
|
OUTPUT = gbtreekey8_out
|
2001-08-23 02:27:54 +08:00
|
|
|
);
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey16_in(cstring)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_in'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey16_out(gbtreekey16)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS cstring
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_out'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
CREATE TYPE gbtreekey16 (
|
2007-11-11 11:25:35 +08:00
|
|
|
INTERNALLENGTH = 16,
|
|
|
|
INPUT = gbtreekey16_in,
|
|
|
|
OUTPUT = gbtreekey16_out
|
2003-02-19 11:46:00 +08:00
|
|
|
);
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey32_in(cstring)
|
2005-07-21 12:15:04 +08:00
|
|
|
RETURNS gbtreekey32
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_in'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey32_out(gbtreekey32)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS cstring
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_out'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2005-07-21 12:15:04 +08:00
|
|
|
CREATE TYPE gbtreekey32 (
|
2007-11-11 11:25:35 +08:00
|
|
|
INTERNALLENGTH = 32,
|
|
|
|
INPUT = gbtreekey32_in,
|
|
|
|
OUTPUT = gbtreekey32_out
|
2003-02-19 11:46:00 +08:00
|
|
|
);
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey_var_in(cstring)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey_var
|
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_in'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbtreekey_var_out(gbtreekey_var)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS cstring
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME', 'gbtreekey_out'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
CREATE TYPE gbtreekey_var (
|
2007-11-11 11:25:35 +08:00
|
|
|
INTERNALLENGTH = VARIABLE,
|
|
|
|
INPUT = gbtreekey_var_in,
|
|
|
|
OUTPUT = gbtreekey_var_out,
|
|
|
|
STORAGE = EXTENDED
|
2003-02-19 11:46:00 +08:00
|
|
|
);
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-03-03 03:43:24 +08:00
|
|
|
--distance operators
|
|
|
|
|
|
|
|
CREATE FUNCTION cash_dist(money, money)
|
|
|
|
RETURNS money
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = money,
|
|
|
|
RIGHTARG = money,
|
|
|
|
PROCEDURE = cash_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION date_dist(date, date)
|
|
|
|
RETURNS int4
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = date,
|
|
|
|
RIGHTARG = date,
|
|
|
|
PROCEDURE = date_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION float4_dist(float4, float4)
|
|
|
|
RETURNS float4
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = float4,
|
|
|
|
RIGHTARG = float4,
|
|
|
|
PROCEDURE = float4_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION float8_dist(float8, float8)
|
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = float8,
|
|
|
|
RIGHTARG = float8,
|
|
|
|
PROCEDURE = float8_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION int2_dist(int2, int2)
|
|
|
|
RETURNS int2
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = int2,
|
|
|
|
RIGHTARG = int2,
|
|
|
|
PROCEDURE = int2_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION int4_dist(int4, int4)
|
|
|
|
RETURNS int4
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = int4,
|
|
|
|
RIGHTARG = int4,
|
|
|
|
PROCEDURE = int4_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION int8_dist(int8, int8)
|
|
|
|
RETURNS int8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = int8,
|
|
|
|
RIGHTARG = int8,
|
|
|
|
PROCEDURE = int8_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION interval_dist(interval, interval)
|
|
|
|
RETURNS interval
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = interval,
|
|
|
|
RIGHTARG = interval,
|
|
|
|
PROCEDURE = interval_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION oid_dist(oid, oid)
|
|
|
|
RETURNS oid
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = oid,
|
|
|
|
RIGHTARG = oid,
|
|
|
|
PROCEDURE = oid_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION time_dist(time, time)
|
|
|
|
RETURNS interval
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = time,
|
|
|
|
RIGHTARG = time,
|
|
|
|
PROCEDURE = time_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION ts_dist(timestamp, timestamp)
|
|
|
|
RETURNS interval
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = timestamp,
|
|
|
|
RIGHTARG = timestamp,
|
|
|
|
PROCEDURE = ts_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
|
|
|
|
|
|
|
CREATE FUNCTION tstz_dist(timestamptz, timestamptz)
|
|
|
|
RETURNS interval
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
|
|
|
CREATE OPERATOR <-> (
|
|
|
|
LEFTARG = timestamptz,
|
|
|
|
RIGHTARG = timestamptz,
|
|
|
|
PROCEDURE = tstz_dist,
|
|
|
|
COMMUTATOR = '<->'
|
|
|
|
);
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
|
2001-08-23 02:27:54 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
-- oid ops
|
2001-08-23 02:27:54 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_oid_consistent(internal,oid,int2,oid,internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_oid_distance(internal,oid,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_oid_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_oid_compress(internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_decompress(internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_var_decompress(internal)
|
2005-03-01 23:40:04 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2005-03-01 23:40:04 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_var_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_oid_penalty(internal,internal,internal)
|
2003-03-21 02:59:18 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_oid_picksplit(internal, internal)
|
2003-03-21 02:59:18 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_oid_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey8
|
2003-03-21 02:59:18 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_oid_same(gbtreekey8, gbtreekey8, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_oid_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE oid USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_oid_consistent (internal, oid, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_oid_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_oid_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_oid_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_oid_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_oid_same (gbtreekey8, gbtreekey8, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey8;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
-- Add operators that are new in 9.1. We do it like this, leaving them
|
|
|
|
-- "loose" in the operator family rather than bound into the opclass, because
|
|
|
|
-- that's the only state that can be reproduced during an upgrade from 9.0.
|
|
|
|
ALTER OPERATOR FAMILY gist_oid_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (oid, oid) ,
|
|
|
|
OPERATOR 15 <-> (oid, oid) FOR ORDER BY pg_catalog.oid_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (oid, oid) gbt_oid_distance (internal, oid, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
-- Also add support function for index-only-scans, added in 9.5.
|
|
|
|
FUNCTION 9 (oid, oid) gbt_oid_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- int2 ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int2_consistent(internal,int2,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int2_distance(internal,int2,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int2_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_int2_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int2_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int2_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int2_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey4
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int2_same(gbtreekey4, gbtreekey4, internal)
|
2003-03-21 02:59:18 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_int2_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE int2 USING gist
|
2003-03-21 02:59:18 +08:00
|
|
|
AS
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 1 < ,
|
2003-03-21 02:59:18 +08:00
|
|
|
OPERATOR 2 <= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 3 = ,
|
2003-03-21 02:59:18 +08:00
|
|
|
OPERATOR 4 >= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_int2_consistent (internal, int2, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_int2_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_int2_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_int2_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_int2_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_int2_same (gbtreekey4, gbtreekey4, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey4;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_int2_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (int2, int2) ,
|
|
|
|
OPERATOR 15 <-> (int2, int2) FOR ORDER BY pg_catalog.integer_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (int2, int2) gbt_int2_distance (internal, int2, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (int2, int2) gbt_int2_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
2003-03-21 02:59:18 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- int4 ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int4_consistent(internal,int4,int2,oid,internal)
|
2003-03-21 02:59:18 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int4_distance(internal,int4,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int4_compress(internal)
|
2003-03-21 02:59:18 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-03-21 02:59:18 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_int4_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int4_penalty(internal,internal,internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int4_picksplit(internal, internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int4_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey8
|
2002-10-19 02:41:22 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int4_same(gbtreekey8, gbtreekey8, internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2002-07-31 01:34:37 +08:00
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_int4_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE int4 USING gist
|
2002-10-19 02:41:22 +08:00
|
|
|
AS
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 1 < ,
|
2002-07-31 01:34:37 +08:00
|
|
|
OPERATOR 2 <= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 3 = ,
|
2002-07-31 01:34:37 +08:00
|
|
|
OPERATOR 4 >= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_int4_consistent (internal, int4, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_int4_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_int4_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_int4_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_int4_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_int4_same (gbtreekey8, gbtreekey8, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey8;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_int4_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (int4, int4) ,
|
|
|
|
OPERATOR 15 <-> (int4, int4) FOR ORDER BY pg_catalog.integer_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (int4, int4) gbt_int4_distance (internal, int4, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (int4, int4) gbt_int4_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
|
|
|
|
2003-02-19 11:46:00 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- int8 ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int8_consistent(internal,int8,int2,oid,internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int8_distance(internal,int8,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int8_compress(internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_int8_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int8_penalty(internal,internal,internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_int8_picksplit(internal, internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int8_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
2003-02-19 11:46:00 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_int8_same(gbtreekey16, gbtreekey16, internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_int8_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE int8 USING gist
|
2003-02-19 11:46:00 +08:00
|
|
|
AS
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 1 < ,
|
2003-02-19 11:46:00 +08:00
|
|
|
OPERATOR 2 <= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 3 = ,
|
2003-02-19 11:46:00 +08:00
|
|
|
OPERATOR 4 >= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_int8_consistent (internal, int8, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_int8_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_int8_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_int8_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_int8_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_int8_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_int8_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (int8, int8) ,
|
|
|
|
OPERATOR 15 <-> (int8, int8) FOR ORDER BY pg_catalog.integer_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (int8, int8) gbt_int8_distance (internal, int8, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (int8, int8) gbt_int8_fetch (internal) ;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- float4 ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float4_consistent(internal,float4,int2,oid,internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_float4_distance(internal,float4,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float4_compress(internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_float4_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float4_penalty(internal,internal,internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float4_picksplit(internal, internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_float4_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey8
|
2003-02-19 11:46:00 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_float4_same(gbtreekey8, gbtreekey8, internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_float4_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE float4 USING gist
|
2003-02-19 11:46:00 +08:00
|
|
|
AS
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 1 < ,
|
2003-02-19 11:46:00 +08:00
|
|
|
OPERATOR 2 <= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 3 = ,
|
2003-02-19 11:46:00 +08:00
|
|
|
OPERATOR 4 >= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_float4_consistent (internal, float4, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_float4_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_float4_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_float4_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_float4_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_float4_same (gbtreekey8, gbtreekey8, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey8;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_float4_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (float4, float4) ,
|
|
|
|
OPERATOR 15 <-> (float4, float4) FOR ORDER BY pg_catalog.float_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (float4, float4) gbt_float4_distance (internal, float4, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (float4, float4) gbt_float4_fetch (internal) ;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- float8 ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float8_consistent(internal,float8,int2,oid,internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_float8_distance(internal,float8,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float8_compress(internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_float8_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float8_penalty(internal,internal,internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_float8_picksplit(internal, internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_float8_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
2003-02-19 11:46:00 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_float8_same(gbtreekey16, gbtreekey16, internal)
|
2003-02-19 11:46:00 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_float8_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE float8 USING gist
|
2003-02-19 11:46:00 +08:00
|
|
|
AS
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 1 < ,
|
2003-02-19 11:46:00 +08:00
|
|
|
OPERATOR 2 <= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 3 = ,
|
2003-02-19 11:46:00 +08:00
|
|
|
OPERATOR 4 >= ,
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_float8_consistent (internal, float8, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_float8_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_float8_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_float8_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_float8_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_float8_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
2003-02-19 11:46:00 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_float8_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (float8, float8) ,
|
|
|
|
OPERATOR 15 <-> (float8, float8) FOR ORDER BY pg_catalog.float_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (float8, float8) gbt_float8_distance (internal, float8, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (float8, float8) gbt_float8_fetch (internal) ;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- timestamp ops
|
2010-11-24 04:27:50 +08:00
|
|
|
--
|
2001-08-23 02:27:54 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_ts_consistent(internal,timestamp,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
2001-08-23 02:27:54 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_ts_distance(internal,timestamp,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_tstz_consistent(internal,timestamptz,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
2001-08-23 02:27:54 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_tstz_distance(internal,timestamptz,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_ts_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_tstz_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_ts_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_ts_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_ts_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_ts_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_ts_same(gbtreekey16, gbtreekey16, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_timestamp_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE timestamp USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_ts_consistent (internal, timestamp, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_ts_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_ts_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_ts_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_ts_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_ts_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_timestamp_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (timestamp, timestamp) ,
|
|
|
|
OPERATOR 15 <-> (timestamp, timestamp) FOR ORDER BY pg_catalog.interval_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (timestamp, timestamp) gbt_ts_distance (internal, timestamp, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (timestamp, timestamp) gbt_ts_fetch (internal) ;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_timestamptz_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE timestamptz USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_tstz_consistent (internal, timestamptz, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_ts_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_tstz_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_ts_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_ts_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_ts_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_timestamptz_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (timestamptz, timestamptz) ,
|
|
|
|
OPERATOR 15 <-> (timestamptz, timestamptz) FOR ORDER BY pg_catalog.interval_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (timestamptz, timestamptz) gbt_tstz_distance (internal, timestamptz, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (timestamptz, timestamptz) gbt_ts_fetch (internal) ;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- time ops
|
2010-11-24 04:27:50 +08:00
|
|
|
--
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_time_consistent(internal,time,int2,oid,internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_time_distance(internal,time,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_timetz_consistent(internal,timetz,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_time_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_timetz_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_time_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_time_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_time_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_time_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_time_same(gbtreekey16, gbtreekey16, internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_time_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE time USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_time_consistent (internal, time, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_time_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_time_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_time_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_time_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_time_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_time_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (time, time) ,
|
|
|
|
OPERATOR 15 <-> (time, time) FOR ORDER BY pg_catalog.interval_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (time, time) gbt_time_distance (internal, time, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (time, time) gbt_time_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
CREATE OPERATOR CLASS gist_timetz_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE timetz USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
2008-04-15 01:05:34 +08:00
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
|
|
|
FUNCTION 1 gbt_timetz_consistent (internal, timetz, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_time_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_timetz_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_time_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_time_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_time_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_timetz_ops USING gist ADD
|
|
|
|
OPERATOR 6 <> (timetz, timetz) ;
|
2015-03-28 05:35:16 +08:00
|
|
|
-- no 'fetch' function, as the compress function is lossy.
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- date ops
|
2010-11-24 04:27:50 +08:00
|
|
|
--
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_date_consistent(internal,date,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_date_distance(internal,date,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_date_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_date_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_date_penalty(internal,internal,internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_date_picksplit(internal, internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_date_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey8
|
2002-10-19 02:41:22 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_date_same(gbtreekey8, gbtreekey8, internal)
|
2002-10-19 02:41:22 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2001-08-23 02:27:54 +08:00
|
|
|
|
2002-07-31 01:34:37 +08:00
|
|
|
-- Create the operator class
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
CREATE OPERATOR CLASS gist_date_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE date USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_date_consistent (internal, date, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_date_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_date_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_date_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_date_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_date_same (gbtreekey8, gbtreekey8, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey8;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_date_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (date, date) ,
|
|
|
|
OPERATOR 15 <-> (date, date) FOR ORDER BY pg_catalog.integer_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (date, date) gbt_date_distance (internal, date, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (date, date) gbt_date_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- interval ops
|
2010-11-24 04:27:50 +08:00
|
|
|
--
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_intv_consistent(internal,interval,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_intv_distance(internal,interval,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_intv_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_intv_decompress(internal)
|
2004-06-03 20:26:10 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2004-06-03 20:26:10 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_intv_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_intv_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_intv_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
2010-11-24 04:27:50 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_intv_union(internal, internal)
|
2005-07-21 12:15:04 +08:00
|
|
|
RETURNS gbtreekey32
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_intv_same(gbtreekey32, gbtreekey32, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_interval_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE interval USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_intv_consistent (internal, interval, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_intv_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_intv_compress (internal),
|
2004-06-03 20:26:10 +08:00
|
|
|
FUNCTION 4 gbt_intv_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_intv_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_intv_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_intv_same (gbtreekey32, gbtreekey32, internal),
|
2005-07-21 12:15:04 +08:00
|
|
|
STORAGE gbtreekey32;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_interval_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (interval, interval) ,
|
|
|
|
OPERATOR 15 <-> (interval, interval) FOR ORDER BY pg_catalog.interval_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (interval, interval) gbt_intv_distance (internal, interval, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (interval, interval) gbt_intv_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- cash ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_cash_consistent(internal,money,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_cash_distance(internal,money,int2,oid,internal)
|
2011-03-03 03:43:24 +08:00
|
|
|
RETURNS float8
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_cash_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_cash_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_cash_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_cash_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_cash_union(internal, internal)
|
|
|
|
RETURNS gbtreekey16
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_cash_same(gbtreekey16, gbtreekey16, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_cash_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE money USING gist
|
2002-10-19 02:41:22 +08:00
|
|
|
AS
|
2002-07-31 01:34:37 +08:00
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_cash_consistent (internal, money, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_cash_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_cash_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_cash_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_cash_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_cash_same (gbtreekey16, gbtreekey16, internal),
|
2007-01-04 02:57:19 +08:00
|
|
|
STORAGE gbtreekey16;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_cash_ops USING gist ADD
|
2011-03-03 03:43:24 +08:00
|
|
|
OPERATOR 6 <> (money, money) ,
|
|
|
|
OPERATOR 15 <-> (money, money) FOR ORDER BY pg_catalog.money_ops ,
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 8 (money, money) gbt_cash_distance (internal, money, int2, oid, internal) ,
|
2015-03-28 05:35:16 +08:00
|
|
|
FUNCTION 9 (money, money) gbt_cash_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- macaddr ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_macad_consistent(internal,macaddr,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_macad_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2015-03-28 05:35:16 +08:00
|
|
|
CREATE FUNCTION gbt_macad_fetch(internal)
|
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_macad_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_macad_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_macad_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_macad_same(gbtreekey16, gbtreekey16, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_macaddr_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE macaddr USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_macad_consistent (internal, macaddr, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_macad_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_macad_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_macad_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_macad_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_macad_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_macaddr_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (macaddr, macaddr) ,
|
|
|
|
FUNCTION 9 (macaddr, macaddr) gbt_macad_fetch (internal);
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- text/ bpchar ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_text_consistent(internal,text,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bpchar_consistent(internal,bpchar,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_text_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bpchar_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_text_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_text_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_text_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey_var
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_text_same(gbtreekey_var, gbtreekey_var, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_text_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE text USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_text_consistent (internal, text, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_text_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_text_compress (internal),
|
2005-03-01 23:40:04 +08:00
|
|
|
FUNCTION 4 gbt_var_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_text_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_text_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_text_same (gbtreekey_var, gbtreekey_var, internal),
|
2010-11-24 04:27:50 +08:00
|
|
|
STORAGE gbtreekey_var;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_text_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (text, text) ,
|
|
|
|
FUNCTION 9 (text, text) gbt_var_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
---- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_bpchar_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE bpchar USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_bpchar_consistent (internal, bpchar , int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_text_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_bpchar_compress (internal),
|
2005-03-01 23:40:04 +08:00
|
|
|
FUNCTION 4 gbt_var_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_text_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_text_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_text_same (gbtreekey_var, gbtreekey_var, internal),
|
2010-11-24 04:27:50 +08:00
|
|
|
STORAGE gbtreekey_var;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_bpchar_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (bpchar, bpchar) ,
|
|
|
|
FUNCTION 9 (bpchar, bpchar) gbt_var_fetch (internal) ;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- bytea ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bytea_consistent(internal,bytea,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bytea_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bytea_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bytea_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_bytea_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey_var
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_bytea_same(gbtreekey_var, gbtreekey_var, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_bytea_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE bytea USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_bytea_consistent (internal, bytea, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_bytea_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_bytea_compress (internal),
|
2005-03-01 23:40:04 +08:00
|
|
|
FUNCTION 4 gbt_var_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_bytea_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_bytea_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_bytea_same (gbtreekey_var, gbtreekey_var, internal),
|
2010-11-24 04:27:50 +08:00
|
|
|
STORAGE gbtreekey_var;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_bytea_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (bytea, bytea) ,
|
|
|
|
FUNCTION 9 (bytea, bytea) gbt_var_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- numeric ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_numeric_consistent(internal,numeric,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_numeric_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_numeric_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_numeric_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_numeric_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey_var
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_numeric_same(gbtreekey_var, gbtreekey_var, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_numeric_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE numeric USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_numeric_consistent (internal, numeric, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_numeric_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_numeric_compress (internal),
|
2005-03-01 23:40:04 +08:00
|
|
|
FUNCTION 4 gbt_var_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_numeric_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_numeric_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_numeric_same (gbtreekey_var, gbtreekey_var, internal),
|
2010-11-24 04:27:50 +08:00
|
|
|
STORAGE gbtreekey_var;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_numeric_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (numeric, numeric) ,
|
|
|
|
FUNCTION 9 (numeric, numeric) gbt_var_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
--
|
|
|
|
--
|
|
|
|
-- bit ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bit_consistent(internal,bit,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bit_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bit_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_bit_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_bit_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey_var
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_bit_same(gbtreekey_var, gbtreekey_var, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_bit_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE bit USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_bit_consistent (internal, bit, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_bit_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_bit_compress (internal),
|
2005-03-01 23:40:04 +08:00
|
|
|
FUNCTION 4 gbt_var_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_bit_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_bit_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_bit_same (gbtreekey_var, gbtreekey_var, internal),
|
2010-11-24 04:27:50 +08:00
|
|
|
STORAGE gbtreekey_var;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_bit_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (bit, bit) ,
|
|
|
|
FUNCTION 9 (bit, bit) gbt_var_fetch (internal) ;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_vbit_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE varbit USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
2008-04-15 01:05:34 +08:00
|
|
|
FUNCTION 1 gbt_bit_consistent (internal, bit, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_bit_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_bit_compress (internal),
|
2005-03-01 23:40:04 +08:00
|
|
|
FUNCTION 4 gbt_var_decompress (internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 5 gbt_bit_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_bit_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_bit_same (gbtreekey_var, gbtreekey_var, internal),
|
2010-11-24 04:27:50 +08:00
|
|
|
STORAGE gbtreekey_var;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_vbit_ops USING gist ADD
|
2015-03-28 05:35:16 +08:00
|
|
|
OPERATOR 6 <> (varbit, varbit) ,
|
|
|
|
FUNCTION 9 (varbit, varbit) gbt_var_fetch (internal) ;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- inet/cidr ops
|
|
|
|
--
|
|
|
|
--
|
|
|
|
--
|
|
|
|
-- define the GiST support methods
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_inet_consistent(internal,inet,int2,oid,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS bool
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_inet_compress(internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_inet_penalty(internal,internal,internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2007-09-30 07:24:39 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
2011-02-14 10:24:14 +08:00
|
|
|
CREATE FUNCTION gbt_inet_picksplit(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_inet_union(internal, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS gbtreekey16
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
CREATE FUNCTION gbt_inet_same(gbtreekey16, gbtreekey16, internal)
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
RETURNS internal
|
|
|
|
AS 'MODULE_PATHNAME'
|
2009-06-12 02:30:03 +08:00
|
|
|
LANGUAGE C IMMUTABLE STRICT;
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
|
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_inet_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE inet USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
2008-04-15 01:05:34 +08:00
|
|
|
OPERATOR 1 < ,
|
|
|
|
OPERATOR 2 <= ,
|
|
|
|
OPERATOR 3 = ,
|
|
|
|
OPERATOR 4 >= ,
|
|
|
|
OPERATOR 5 > ,
|
|
|
|
FUNCTION 1 gbt_inet_consistent (internal, inet, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_inet_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_inet_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_inet_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_inet_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_inet_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
|
|
|
|
2011-02-18 05:37:34 +08:00
|
|
|
ALTER OPERATOR FAMILY gist_inet_ops USING gist ADD
|
|
|
|
OPERATOR 6 <> (inet, inet) ;
|
2015-03-28 05:35:16 +08:00
|
|
|
-- no fetch support, the compress function is lossy
|
2011-02-18 05:37:34 +08:00
|
|
|
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
-- Create the operator class
|
|
|
|
CREATE OPERATOR CLASS gist_cidr_ops
|
2010-11-24 04:27:50 +08:00
|
|
|
DEFAULT FOR TYPE cidr USING gist
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
AS
|
2008-04-15 01:05:34 +08:00
|
|
|
OPERATOR 1 < (inet, inet) ,
|
|
|
|
OPERATOR 2 <= (inet, inet) ,
|
|
|
|
OPERATOR 3 = (inet, inet) ,
|
|
|
|
OPERATOR 4 >= (inet, inet) ,
|
|
|
|
OPERATOR 5 > (inet, inet) ,
|
|
|
|
FUNCTION 1 gbt_inet_consistent (internal, inet, int2, oid, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 2 gbt_inet_union (internal, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
FUNCTION 3 gbt_inet_compress (internal),
|
|
|
|
FUNCTION 4 gbt_decompress (internal),
|
|
|
|
FUNCTION 5 gbt_inet_penalty (internal, internal, internal),
|
|
|
|
FUNCTION 6 gbt_inet_picksplit (internal, internal),
|
Fix assorted inconsistencies in GiST opclass support function declarations.
The conventions specified by the GiST SGML documentation were widely
ignored. For example, the strategy-number argument for "consistent" and
"distance" functions is specified to be a smallint, but most of the
built-in support functions declared it as an integer, and for that matter
the core code passed it using Int32GetDatum not Int16GetDatum. None of
that makes any real difference at runtime, but it's quite confusing for
newcomers to the code, and it makes it very hard to write an amvalidate()
function that checks support function signatures. So let's try to instill
some consistency here.
Another similar issue is that the "query" argument is not of a single
well-defined type, but could have different types depending on the strategy
(corresponding to search operators with different righthand-side argument
types). Some of the functions threw up their hands and declared the query
argument as being of "internal" type, which surely isn't right ("any" would
have been more appropriate); but the majority position seemed to be to
declare it as being of the indexed data type, corresponding to a search
operator with both input types the same. So I've specified a convention
that that's what to do always.
Also, the result of the "union" support function actually must be of the
index's storage type, but the documentation suggested declaring it to
return "internal", and some of the functions followed that. Standardize
on telling the truth, instead.
Similarly, standardize on declaring the "same" function's inputs as
being of the storage type, not "internal".
Also, somebody had forgotten to add the "recheck" argument to both
the documentation of the "distance" support function and all of their
SQL declarations, even though the C code was happily using that argument.
Clean that up too.
Fix up some other omissions in the docs too, such as documenting that
union's second input argument is vestigial.
So far as the errors in core function declarations go, we can just fix
pg_proc.h and bump catversion. Adjusting the erroneous declarations in
contrib modules is more debatable: in principle any change in those
scripts should involve an extension version bump, which is a pain.
However, since these changes are purely cosmetic and make no functional
difference, I think we can get away without doing that.
2016-01-20 01:04:32 +08:00
|
|
|
FUNCTION 7 gbt_inet_same (gbtreekey16, gbtreekey16, internal),
|
New version. Add support for int2, int8, float4, float8, timestamp with/without time zone, time with/without time zone, date, interval, oid, money and macaddr, char, varchar/text, bytea, numeric, bit, varbit, inet/cidr types for GiST
2004-05-28 18:43:32 +08:00
|
|
|
STORAGE gbtreekey16;
|
2011-02-18 05:37:34 +08:00
|
|
|
|
|
|
|
ALTER OPERATOR FAMILY gist_cidr_ops USING gist ADD
|
|
|
|
OPERATOR 6 <> (inet, inet) ;
|
2015-03-28 05:35:16 +08:00
|
|
|
-- no fetch support, the compress function is lossy
|