2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
-- Test cube datatype
|
|
|
|
--
|
2011-02-14 09:06:41 +08:00
|
|
|
CREATE EXTENSION cube;
|
2016-11-30 04:05:22 +08:00
|
|
|
-- Check whether any of our opclasses fail amvalidate
|
|
|
|
SELECT amname, opcname
|
|
|
|
FROM pg_opclass opc LEFT JOIN pg_am am ON am.oid = opcmethod
|
|
|
|
WHERE opc.oid >= 16384 AND NOT amvalidate(opc.oid);
|
|
|
|
amname | opcname
|
|
|
|
--------+---------
|
|
|
|
(0 rows)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
-- testing the input and output functions
|
|
|
|
--
|
|
|
|
-- Any number (a one-dimensional point)
|
|
|
|
SELECT '1'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(-1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1.'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1.'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(-1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '.1'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-------
|
|
|
|
(0.1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-.1'::cube AS cube;
|
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(-0.1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1.0'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1.0'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(-1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1e27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1e27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1.0e27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1.0e27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1e+27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1e+27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1.0e+27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1.0e+27'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e+027)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1e-7'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e-007)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1e-7'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e-007)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1.0e-7'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e-007)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1.0e-7'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e-007)
|
|
|
|
(1 row)
|
|
|
|
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
SELECT '1e-300'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1e-300)
|
2004-10-25 06:11:37 +08:00
|
|
|
(1 row)
|
|
|
|
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
SELECT '-1e-300'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(-1e-300)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'infinity'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------------
|
|
|
|
(Infinity)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-infinity'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-------------
|
|
|
|
(-Infinity)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'NaN'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-------
|
|
|
|
(NaN)
|
2004-10-25 06:11:37 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1234567890123456'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-------------------------
|
|
|
|
(1.23456789012346e+015)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '+1234567890123456'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-------------------------
|
|
|
|
(1.23456789012346e+015)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1234567890123456'::cube AS cube;
|
|
|
|
cube
|
|
|
|
--------------------------
|
|
|
|
(-1.23456789012346e+015)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '.1234567890123456'::cube AS cube;
|
|
|
|
cube
|
|
|
|
---------------------
|
|
|
|
(0.123456789012346)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '+.1234567890123456'::cube AS cube;
|
|
|
|
cube
|
|
|
|
---------------------
|
|
|
|
(0.123456789012346)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-.1234567890123456'::cube AS cube;
|
|
|
|
cube
|
|
|
|
----------------------
|
|
|
|
(-0.123456789012346)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- simple lists (points)
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
SELECT '()'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
()
|
|
|
|
(1 row)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '1,2'::cube AS cube;
|
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(1, 2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1,2)'::cube AS cube;
|
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(1, 2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1,2,3,4,5'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------------
|
|
|
|
(1, 2, 3, 4, 5)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1,2,3,4,5)'::cube AS cube;
|
|
|
|
cube
|
|
|
|
-----------------
|
|
|
|
(1, 2, 3, 4, 5)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- double lists (cubes)
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
SELECT '(),()'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
()
|
|
|
|
(1 row)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '(0),(0)'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(0),(1)'::cube AS cube;
|
|
|
|
cube
|
|
|
|
---------
|
|
|
|
(0),(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(0),(0)]'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(0),(1)]'::cube AS cube;
|
|
|
|
cube
|
|
|
|
---------
|
|
|
|
(0),(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(0,0,0,0),(0,0,0,0)'::cube AS cube;
|
|
|
|
cube
|
|
|
|
--------------
|
|
|
|
(0, 0, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(0,0,0,0),(1,0,0,0)'::cube AS cube;
|
|
|
|
cube
|
|
|
|
---------------------------
|
|
|
|
(0, 0, 0, 0),(1, 0, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(0,0,0,0),(0,0,0,0)]'::cube AS cube;
|
|
|
|
cube
|
|
|
|
--------------
|
|
|
|
(0, 0, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(0,0,0,0),(1,0,0,0)]'::cube AS cube;
|
|
|
|
cube
|
|
|
|
---------------------------
|
|
|
|
(0, 0, 0, 0),(1, 0, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- invalid input: parse errors
|
|
|
|
SELECT ''::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT ''::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at end of input
|
|
|
|
SELECT 'ABC'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT 'ABC'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "A"
|
|
|
|
SELECT '[]'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[]'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "]"
|
|
|
|
SELECT '[()]'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[()]'::cube AS cube;
|
|
|
|
^
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
DETAIL: syntax error at or near "]"
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '[(1)]'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1)]'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "]"
|
|
|
|
SELECT '[(1),]'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1),]'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "]"
|
|
|
|
SELECT '[(1),2]'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1),2]'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "2"
|
|
|
|
SELECT '[(1),(2),(3)]'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1),(2),(3)]'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ","
|
|
|
|
SELECT '1,'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1,'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at end of input
|
|
|
|
SELECT '1,2,'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1,2,'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at end of input
|
|
|
|
SELECT '1,,2'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1,,2'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ","
|
|
|
|
SELECT '(1,)'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,)'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ")"
|
|
|
|
SELECT '(1,2,)'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,2,)'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ")"
|
|
|
|
SELECT '(1,,2)'::cube AS cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,,2)'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ","
|
|
|
|
-- invalid input: semantic errors and trailing garbage
|
|
|
|
SELECT '[(1),(2)],'::cube AS cube; -- 0
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1),(2)],'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ","
|
|
|
|
SELECT '[(1,2,3),(2,3)]'::cube AS cube; -- 1
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1,2,3),(2,3)]'::cube AS cube;
|
|
|
|
^
|
2006-03-02 07:00:56 +08:00
|
|
|
DETAIL: Different point dimensions in (1,2,3) and (2,3).
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '[(1,2),(1,2,3)]'::cube AS cube; -- 1
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '[(1,2),(1,2,3)]'::cube AS cube;
|
|
|
|
^
|
2006-03-02 07:00:56 +08:00
|
|
|
DETAIL: Different point dimensions in (1,2) and (1,2,3).
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '(1),(2),'::cube AS cube; -- 2
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1),(2),'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ","
|
|
|
|
SELECT '(1,2,3),(2,3)'::cube AS cube; -- 3
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,2,3),(2,3)'::cube AS cube;
|
|
|
|
^
|
2006-03-02 07:00:56 +08:00
|
|
|
DETAIL: Different point dimensions in (1,2,3) and (2,3).
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '(1,2),(1,2,3)'::cube AS cube; -- 3
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,2),(1,2,3)'::cube AS cube;
|
|
|
|
^
|
2006-03-02 07:00:56 +08:00
|
|
|
DETAIL: Different point dimensions in (1,2) and (1,2,3).
|
2004-10-25 06:11:37 +08:00
|
|
|
SELECT '(1,2,3)ab'::cube AS cube; -- 4
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,2,3)ab'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "a"
|
|
|
|
SELECT '(1,2,3)a'::cube AS cube; -- 5
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,2,3)a'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "a"
|
|
|
|
SELECT '(1,2)('::cube AS cube; -- 5
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '(1,2)('::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "("
|
|
|
|
SELECT '1,2ab'::cube AS cube; -- 6
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1,2ab'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "a"
|
|
|
|
SELECT '1 e7'::cube AS cube; -- 6
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1 e7'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "e"
|
|
|
|
SELECT '1,2a'::cube AS cube; -- 7
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1,2a'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near "a"
|
|
|
|
SELECT '1..2'::cube AS cube; -- 7
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: SELECT '1..2'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
DETAIL: syntax error at or near ".2"
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
SELECT '-1e-700'::cube AS cube; -- out of range
|
|
|
|
ERROR: "-1e-700" is out of range for type double precision
|
|
|
|
LINE 1: SELECT '-1e-700'::cube AS cube;
|
|
|
|
^
|
2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
-- Testing building cubes from float8 values
|
|
|
|
--
|
|
|
|
SELECT cube(0::float8);
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(1::float8);
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(1,2);
|
|
|
|
cube
|
|
|
|
---------
|
|
|
|
(1),(2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,2),3);
|
|
|
|
cube
|
|
|
|
---------------
|
|
|
|
(1, 3),(2, 3)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,2),3,4);
|
|
|
|
cube
|
|
|
|
---------------
|
|
|
|
(1, 3),(2, 4)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(cube(1,2),3,4),5);
|
|
|
|
cube
|
|
|
|
---------------------
|
|
|
|
(1, 3, 5),(2, 4, 5)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(cube(1,2),3,4),5,6);
|
|
|
|
cube
|
|
|
|
---------------------
|
|
|
|
(1, 3, 5),(2, 4, 6)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Test that the text -> cube cast was installed.
|
|
|
|
--
|
|
|
|
SELECT '(0)'::text::cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
2006-07-28 05:55:09 +08:00
|
|
|
--
|
|
|
|
-- Test the float[] -> cube cast
|
|
|
|
--
|
|
|
|
SELECT cube('{0,1,2}'::float[], '{3,4,5}'::float[]);
|
|
|
|
cube
|
|
|
|
---------------------
|
|
|
|
(0, 1, 2),(3, 4, 5)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube('{0,1,2}'::float[], '{3}'::float[]);
|
|
|
|
ERROR: UR and LL arrays must be of same length
|
|
|
|
SELECT cube(NULL::float[], '{3}'::float[]);
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube('{0,1,2}'::float[]);
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(0, 1, 2)
|
|
|
|
(1 row)
|
|
|
|
|
2010-11-24 04:27:50 +08:00
|
|
|
SELECT cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[3,2,1,1]);
|
2006-07-28 05:55:09 +08:00
|
|
|
cube_subset
|
|
|
|
---------------------------
|
|
|
|
(5, 3, 1, 1),(8, 7, 6, 6)
|
|
|
|
(1 row)
|
|
|
|
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_subset(cube('(1,3,5),(1,3,5)'), ARRAY[3,2,1,1]);
|
|
|
|
cube_subset
|
|
|
|
--------------
|
|
|
|
(5, 3, 1, 1)
|
|
|
|
(1 row)
|
|
|
|
|
2010-11-24 04:27:50 +08:00
|
|
|
SELECT cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[4,0]);
|
2006-07-28 05:55:09 +08:00
|
|
|
ERROR: Index out of bounds
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_subset(cube('(6,7,8),(6,7,8)'), ARRAY[4,0]);
|
|
|
|
ERROR: Index out of bounds
|
|
|
|
--
|
|
|
|
-- Test point processing
|
|
|
|
--
|
|
|
|
SELECT cube('(1,2),(1,2)'); -- cube_in
|
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(1, 2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube('{0,1,2}'::float[], '{0,1,2}'::float[]); -- cube_a_f8_f8
|
|
|
|
cube
|
|
|
|
-----------
|
|
|
|
(0, 1, 2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube('{5,6,7,8}'::float[]); -- cube_a_f8
|
|
|
|
cube
|
|
|
|
--------------
|
|
|
|
(5, 6, 7, 8)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(1.37); -- cube_f8
|
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(1.37)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(1.37, 1.37); -- cube_f8_f8
|
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(1.37)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,1), 42); -- cube_c_f8
|
|
|
|
cube
|
|
|
|
---------
|
|
|
|
(1, 42)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,2), 42); -- cube_c_f8
|
|
|
|
cube
|
|
|
|
-----------------
|
|
|
|
(1, 42),(2, 42)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,1), 42, 42); -- cube_c_f8_f8
|
|
|
|
cube
|
|
|
|
---------
|
|
|
|
(1, 42)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,1), 42, 24); -- cube_c_f8_f8
|
|
|
|
cube
|
|
|
|
-----------------
|
|
|
|
(1, 42),(1, 24)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,2), 42, 42); -- cube_c_f8_f8
|
|
|
|
cube
|
|
|
|
-----------------
|
|
|
|
(1, 42),(2, 42)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(cube(1,2), 42, 24); -- cube_c_f8_f8
|
|
|
|
cube
|
|
|
|
-----------------
|
|
|
|
(1, 42),(2, 24)
|
|
|
|
(1 row)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
-- Testing limit of CUBE_MAX_DIM dimensions check in cube_in.
|
|
|
|
--
|
|
|
|
select '(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)'::cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: select '(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0...
|
|
|
|
^
|
2006-03-02 07:00:56 +08:00
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
2004-10-25 06:11:37 +08:00
|
|
|
select '(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0),(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)'::cube;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-02 04:42:46 +08:00
|
|
|
LINE 1: select '(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0...
|
|
|
|
^
|
2006-03-02 07:00:56 +08:00
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
-- testing the operators
|
|
|
|
--
|
|
|
|
-- equality/inequality:
|
|
|
|
--
|
|
|
|
SELECT '24, 33.20'::cube = '24, 33.20'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '24, 33.20'::cube != '24, 33.20'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '24, 33.20'::cube = '24, 33.21'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '24, 33.20'::cube != '24, 33.21'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube = '(2,0,0,0,0),(3,1,0,0,0)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube = '(2,0,0,0,0),(3,1,0,0,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- "lower than" / "greater than"
|
|
|
|
-- (these operators are not useful for anything but ordering)
|
|
|
|
--
|
|
|
|
SELECT '1'::cube > '2'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1'::cube < '2'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1,1'::cube > '1,2'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1,1'::cube < '1,2'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube > '(2,0,0,0,0),(3,1,0,0,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube < '(2,0,0,0,0),(3,1,0,0,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube > '(2,0,0,0,1),(3,1,0,0,0)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube < '(2,0,0,0,1),(3,1,0,0,0)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube > '(2,0,0,0,0),(3,1,0,0,0)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0),(3,1)'::cube < '(2,0,0,0,0),(3,1,0,0,0)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0,0,0,0),(3,1,0,0,1)'::cube > '(2,0),(3,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0,0,0,0),(3,1,0,0,1)'::cube < '(2,0),(3,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0,0,0,1),(3,1,0,0,0)'::cube > '(2,0),(3,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0,0,0,1),(3,1,0,0,0)'::cube < '(2,0),(3,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0,0,0,0),(3,1,0,0,0)'::cube > '(2,0),(3,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(2,0,0,0,0),(3,1,0,0,0)'::cube < '(2,0),(3,1)'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- "overlap"
|
|
|
|
--
|
|
|
|
SELECT '1'::cube && '1'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1'::cube && '2'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '0'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '1'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '1,1,1'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '[(1,1,1),(2,2,2)]'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '[(1,1),(2,2)]'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '[(2,1,1),(2,2,2)]'::cube AS bool;
|
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- "contained in" (the left operand is the cube entirely enclosed by
|
|
|
|
-- the right operand):
|
|
|
|
--
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0'::cube <@ '0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0,0'::cube <@ '0,0,0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0'::cube <@ '0,0,1'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0,0'::cube <@ '0,0,1'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '1,0,0'::cube <@ '0,0,1'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube <@ '(1,0,0),(0,0,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube <@ '(-1,-1,-1),(1,1,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube <@ '(-1,-1,-1,-1),(1,1,1,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0'::cube <@ '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '1'::cube <@ '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '-1'::cube <@ '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube <@ '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube <@ '(-1,-1),(1,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-2),(1)'::cube <@ '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-2),(1)'::cube <@ '(-1,-1),(1,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- "contains" (the left operand is the cube that entirely encloses the
|
|
|
|
-- right operand)
|
|
|
|
--
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0'::cube @> '0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0,0'::cube @> '0,0,0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0,1'::cube @> '0,0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0,1'::cube @> '0,0,0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '0,0,1'::cube @> '1,0,0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1,-1,-1),(1,1,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1,-1,-1,-1),(1,1,1,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube @> '0'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube @> '1'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube @> '-1'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube @> '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1,-1),(1,1)'::cube @> '(-1),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1),(1)'::cube @> '(-2),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-11 01:36:52 +08:00
|
|
|
SELECT '(-1,-1),(1,1)'::cube @> '(-2),(1)'::cube AS bool;
|
2004-10-25 06:11:37 +08:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Test of distance function
|
|
|
|
--
|
|
|
|
SELECT cube_distance('(0)'::cube,'(2,2,2,2)'::cube);
|
|
|
|
cube_distance
|
|
|
|
---------------
|
|
|
|
4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_distance('(0)'::cube,'(.3,.4)'::cube);
|
|
|
|
cube_distance
|
|
|
|
---------------
|
|
|
|
0.5
|
|
|
|
(1 row)
|
|
|
|
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_distance('(2,3,4)'::cube,'(2,3,4)'::cube);
|
|
|
|
cube_distance
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_distance('(42,42,42,42)'::cube,'(137,137,137,137)'::cube);
|
|
|
|
cube_distance
|
|
|
|
---------------
|
|
|
|
190
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_distance('(42,42,42)'::cube,'(137,137)'::cube);
|
|
|
|
cube_distance
|
|
|
|
------------------
|
|
|
|
140.762210837994
|
|
|
|
(1 row)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
-- Test of cube function (text to cube)
|
|
|
|
--
|
2007-06-06 05:31:09 +08:00
|
|
|
SELECT cube('(1,1.2)'::text);
|
2004-10-25 06:11:37 +08:00
|
|
|
cube
|
|
|
|
----------
|
|
|
|
(1, 1.2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(NULL);
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Test of cube_dim function (dimensions stored in cube)
|
|
|
|
--
|
|
|
|
SELECT cube_dim('(0)'::cube);
|
|
|
|
cube_dim
|
|
|
|
----------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_dim('(0,0)'::cube);
|
|
|
|
cube_dim
|
|
|
|
----------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_dim('(0,0,0)'::cube);
|
|
|
|
cube_dim
|
|
|
|
----------
|
|
|
|
3
|
|
|
|
(1 row)
|
|
|
|
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_dim('(42,42,42),(42,42,42)'::cube);
|
|
|
|
cube_dim
|
|
|
|
----------
|
|
|
|
3
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_dim('(4,8,15,16,23),(4,8,15,16,23)'::cube);
|
|
|
|
cube_dim
|
|
|
|
----------
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
2017-02-06 17:33:58 +08:00
|
|
|
-- Test of cube_ll_coord function (retrieves LL coordinate values)
|
2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 1);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
-1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 2);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
-2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 3);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_ll_coord('(1,2),(1,2)'::cube, 1);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(1,2),(1,2)'::cube, 2);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(1,2),(1,2)'::cube, 3);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(42,137)'::cube, 1);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
42
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(42,137)'::cube, 2);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
137
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ll_coord('(42,137)'::cube, 3);
|
|
|
|
cube_ll_coord
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
2017-02-06 17:33:58 +08:00
|
|
|
-- Test of cube_ur_coord function (retrieves UR coordinate values)
|
2004-10-25 06:11:37 +08:00
|
|
|
--
|
|
|
|
SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 1);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 2);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 3);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_ur_coord('(1,2),(1,2)'::cube, 1);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(1,2),(1,2)'::cube, 2);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(1,2),(1,2)'::cube, 3);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(42,137)'::cube, 1);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
42
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(42,137)'::cube, 2);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
137
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_ur_coord('(42,137)'::cube, 3);
|
|
|
|
cube_ur_coord
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
-- Test of cube_is_point
|
|
|
|
--
|
|
|
|
SELECT cube_is_point('(0)'::cube);
|
|
|
|
cube_is_point
|
|
|
|
---------------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_is_point('(0,1,2)'::cube);
|
|
|
|
cube_is_point
|
|
|
|
---------------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_is_point('(0,1,2),(0,1,2)'::cube);
|
|
|
|
cube_is_point
|
|
|
|
---------------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_is_point('(0,1,2),(-1,1,2)'::cube);
|
|
|
|
cube_is_point
|
|
|
|
---------------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_is_point('(0,1,2),(0,-1,2)'::cube);
|
|
|
|
cube_is_point
|
|
|
|
---------------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_is_point('(0,1,2),(0,1,-2)'::cube);
|
|
|
|
cube_is_point
|
|
|
|
---------------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Test of cube_enlarge (enlarging and shrinking cubes)
|
|
|
|
--
|
|
|
|
SELECT cube_enlarge('(0)'::cube, 0, 0);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, 0, 1);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, 0, 2);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2),(-2)'::cube, 0, 4);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(-2),(2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, 1, 0);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(-1),(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, 1, 1);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(-1),(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, 1, 2);
|
|
|
|
cube_enlarge
|
|
|
|
-----------------
|
|
|
|
(-1, -1),(1, 1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2),(-2)'::cube, 1, 4);
|
|
|
|
cube_enlarge
|
|
|
|
-------------------------------
|
|
|
|
(-3, -1, -1, -1),(3, 1, 1, 1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, -1, 0);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, -1, 1);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0)'::cube, -1, 2);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2),(-2)'::cube, -1, 4);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(-1),(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0,0,0)'::cube, 1, 0);
|
|
|
|
cube_enlarge
|
|
|
|
------------------------
|
|
|
|
(-1, -1, -1),(1, 1, 1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(0,0,0)'::cube, 1, 2);
|
|
|
|
cube_enlarge
|
|
|
|
------------------------
|
|
|
|
(-1, -1, -1),(1, 1, 1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, 1, 2);
|
|
|
|
cube_enlarge
|
|
|
|
-----------------
|
|
|
|
(-4, -3),(3, 8)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, 3, 2);
|
|
|
|
cube_enlarge
|
|
|
|
------------------
|
|
|
|
(-6, -5),(5, 10)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, -1, 2);
|
|
|
|
cube_enlarge
|
|
|
|
-----------------
|
|
|
|
(-2, -1),(1, 6)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, -3, 2);
|
|
|
|
cube_enlarge
|
|
|
|
---------------------
|
|
|
|
(-0.5, 1),(-0.5, 4)
|
|
|
|
(1 row)
|
|
|
|
|
Extend cube on-disk format to pack points more tightly.
If the lower left and upper right corners of a cube are the same, set a
flag in the cube header, and only store one copy of the coordinates. That
cuts the on-disk size into half for the common case that the cube datatype
is used to represent points rather than boxes.
The new format is backwards-compatible with the old one, so pg_upgrade
still works. However, to get the space savings, the data needs to be
rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old
Datums will just be moved to the new heap/index as is. A pg_dump and
reload, or something similar like casting to text and back, will do the
trick.
This patch deliberately doesn't update all the alternative expected output
files, as I don't have access to machines that produce those outputs. I'm
not sure if they are still relevant, but if they are, the buildfarm will
tell us and produce the diff required to fix it. If none of the buildfarm
animals need them, they should be removed altogether.
Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
|
|
|
SELECT cube_enlarge('(42,-23,-23),(42,23,23)'::cube, -23, 5);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(42, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_enlarge('(42,-23,-23),(42,23,23)'::cube, -24, 5);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(42, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Test of cube_union (MBR for two cubes)
|
|
|
|
--
|
|
|
|
SELECT cube_union('(1,2),(3,4)'::cube, '(5,6,7),(8,9,10)'::cube);
|
|
|
|
cube_union
|
|
|
|
----------------------
|
|
|
|
(1, 2, 0),(8, 9, 10)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_union('(1,2)'::cube, '(4,2,0,0)'::cube);
|
|
|
|
cube_union
|
|
|
|
---------------------------
|
|
|
|
(1, 2, 0, 0),(4, 2, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_union('(1,2),(1,2)'::cube, '(4,2),(4,2)'::cube);
|
|
|
|
cube_union
|
|
|
|
---------------
|
|
|
|
(1, 2),(4, 2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_union('(1,2),(1,2)'::cube, '(1,2),(1,2)'::cube);
|
|
|
|
cube_union
|
|
|
|
------------
|
|
|
|
(1, 2)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_union('(1,2),(1,2)'::cube, '(1,2,0),(1,2,0)'::cube);
|
|
|
|
cube_union
|
|
|
|
------------
|
|
|
|
(1, 2, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Test of cube_inter
|
|
|
|
--
|
|
|
|
SELECT cube_inter('(1,2),(10,11)'::cube, '(3,4), (16,15)'::cube); -- intersects
|
|
|
|
cube_inter
|
|
|
|
-----------------
|
|
|
|
(3, 4),(10, 11)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_inter('(1,2),(10,11)'::cube, '(3,4), (6,5)'::cube); -- includes
|
|
|
|
cube_inter
|
|
|
|
---------------
|
|
|
|
(3, 4),(6, 5)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_inter('(1,2),(10,11)'::cube, '(13,14), (16,15)'::cube); -- no intersection
|
|
|
|
cube_inter
|
|
|
|
-------------------
|
|
|
|
(13, 14),(10, 11)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_inter('(1,2),(10,11)'::cube, '(3,14), (16,15)'::cube); -- no intersection, but one dimension intersects
|
|
|
|
cube_inter
|
|
|
|
------------------
|
|
|
|
(3, 14),(10, 11)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_inter('(1,2),(10,11)'::cube, '(10,11), (16,15)'::cube); -- point intersection
|
|
|
|
cube_inter
|
|
|
|
------------
|
|
|
|
(10, 11)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_inter('(1,2,3)'::cube, '(1,2,3)'::cube); -- point args
|
|
|
|
cube_inter
|
|
|
|
------------
|
|
|
|
(1, 2, 3)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_inter('(1,2,3)'::cube, '(5,6,3)'::cube); -- point args
|
|
|
|
cube_inter
|
|
|
|
---------------------
|
|
|
|
(5, 6, 3),(1, 2, 3)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Test of cube_size
|
|
|
|
--
|
|
|
|
SELECT cube_size('(4,8),(15,16)'::cube);
|
|
|
|
cube_size
|
|
|
|
-----------
|
|
|
|
88
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube_size('(42,137)'::cube);
|
|
|
|
cube_size
|
|
|
|
-----------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
2015-12-18 19:38:27 +08:00
|
|
|
-- Test of distances
|
|
|
|
--
|
|
|
|
SELECT cube_distance('(1,1)'::cube, '(4,5)'::cube);
|
|
|
|
cube_distance
|
|
|
|
---------------
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1,1)'::cube <-> '(4,5)'::cube as d_e;
|
|
|
|
d_e
|
|
|
|
-----
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT distance_chebyshev('(1,1)'::cube, '(4,5)'::cube);
|
|
|
|
distance_chebyshev
|
|
|
|
--------------------
|
|
|
|
4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1,1)'::cube <=> '(4,5)'::cube as d_c;
|
|
|
|
d_c
|
|
|
|
-----
|
|
|
|
4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT distance_taxicab('(1,1)'::cube, '(4,5)'::cube);
|
|
|
|
distance_taxicab
|
|
|
|
------------------
|
|
|
|
7
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1,1)'::cube <#> '(4,5)'::cube as d_t;
|
|
|
|
d_t
|
|
|
|
-----
|
|
|
|
7
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- zero for overlapping
|
|
|
|
SELECT cube_distance('(2,2),(10,10)'::cube, '(0,0),(5,5)'::cube);
|
|
|
|
cube_distance
|
|
|
|
---------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT distance_chebyshev('(2,2),(10,10)'::cube, '(0,0),(5,5)'::cube);
|
|
|
|
distance_chebyshev
|
|
|
|
--------------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT distance_taxicab('(2,2),(10,10)'::cube, '(0,0),(5,5)'::cube);
|
|
|
|
distance_taxicab
|
|
|
|
------------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- coordinate access
|
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
10
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])->1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
40
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->6;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
60
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->0;
|
2015-12-29 03:39:09 +08:00
|
|
|
ERROR: cube index 0 is out of bounds
|
2015-12-18 19:38:27 +08:00
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->7;
|
2015-12-29 03:39:09 +08:00
|
|
|
ERROR: cube index 7 is out of bounds
|
2015-12-18 19:38:27 +08:00
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->-1;
|
2015-12-29 03:39:09 +08:00
|
|
|
ERROR: cube index -1 is out of bounds
|
2015-12-18 19:38:27 +08:00
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->-6;
|
2015-12-29 03:39:09 +08:00
|
|
|
ERROR: cube index -6 is out of bounds
|
2015-12-18 19:38:27 +08:00
|
|
|
SELECT cube(array[10,20,30])->3;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
30
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[10,20,30])->6;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
30
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[10,20,30])->-6;
|
2015-12-29 03:39:09 +08:00
|
|
|
ERROR: cube index -6 is out of bounds
|
2015-12-18 19:38:27 +08:00
|
|
|
-- "normalized" coordinate access
|
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])~>1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
10
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
10
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])~>2;
|
|
|
|
?column?
|
|
|
|
----------
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
40
|
2015-12-18 19:38:27 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>2;
|
|
|
|
?column?
|
|
|
|
----------
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
40
|
2015-12-18 19:38:27 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])~>3;
|
|
|
|
?column?
|
|
|
|
----------
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
20
|
2015-12-18 19:38:27 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>3;
|
|
|
|
?column?
|
|
|
|
----------
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
20
|
2015-12-18 19:38:27 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>0;
|
2018-01-11 19:49:36 +08:00
|
|
|
ERROR: zero cube index is not defined
|
2015-12-18 19:38:27 +08:00
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>4;
|
|
|
|
?column?
|
|
|
|
----------
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
50
|
2015-12-18 19:38:27 +08:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>(-1);
|
2018-01-11 19:49:36 +08:00
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
-10
|
|
|
|
(1 row)
|
|
|
|
|
2004-10-25 06:11:37 +08:00
|
|
|
-- Load some example data and build the index
|
2010-11-24 04:27:50 +08:00
|
|
|
--
|
2004-10-25 06:11:37 +08:00
|
|
|
CREATE TABLE test_cube (c cube);
|
|
|
|
\copy test_cube from 'data/test_cube.data'
|
|
|
|
CREATE INDEX test_cube_ix ON test_cube USING gist (c);
|
2010-11-24 04:27:50 +08:00
|
|
|
SELECT * FROM test_cube WHERE c && '(3000,1000),(0,0)' ORDER BY c;
|
2004-10-25 06:11:37 +08:00
|
|
|
c
|
|
|
|
--------------------------
|
2006-07-28 05:55:09 +08:00
|
|
|
(337, 455),(240, 359)
|
2004-10-25 06:11:37 +08:00
|
|
|
(759, 187),(662, 163)
|
|
|
|
(1444, 403),(1346, 344)
|
|
|
|
(1594, 1043),(1517, 971)
|
2006-07-28 05:55:09 +08:00
|
|
|
(2424, 160),(2424, 81)
|
2004-10-25 06:11:37 +08:00
|
|
|
(5 rows)
|
|
|
|
|
2010-11-24 04:27:50 +08:00
|
|
|
-- Test sorting
|
|
|
|
SELECT * FROM test_cube WHERE c && '(3000,1000),(0,0)' GROUP BY c ORDER BY c;
|
2004-10-25 06:11:37 +08:00
|
|
|
c
|
|
|
|
--------------------------
|
|
|
|
(337, 455),(240, 359)
|
|
|
|
(759, 187),(662, 163)
|
|
|
|
(1444, 403),(1346, 344)
|
|
|
|
(1594, 1043),(1517, 971)
|
|
|
|
(2424, 160),(2424, 81)
|
|
|
|
(5 rows)
|
|
|
|
|
Support index-only scans in contrib/cube and contrib/seg GiST indexes.
To do this, we only have to remove the compress and decompress support
functions, which have never done anything more than detoasting.
In the wake of commit d3a4f89d8, this results in automatically enabling
index-only scans, since the core code will now know that the stored
representation is the same as the original data (up to detoasting).
The only exciting part of this is that ALTER OPERATOR FAMILY lacks
a way to drop a support function that was declared as being part of
an opclass rather than being loose in the family. For the moment,
we'll hack our way to a solution with a manual update of the pg_depend
entry type, which is what distinguishes the two cases. Perhaps
someday it'll be worth providing a cleaner way to do that, but for
now it seems like a very niche problem.
Note that the underlying C functions remain, to support use of the shared
libraries with older versions of the modules' SQL declarations. Someday
we may be able to remove them, but not soon.
Andrey Borodin, reviewed by me
Discussion: https://postgr.es/m/D0F53A05-4F4A-4DEC-8339-3C069FA0EE11@yandex-team.ru
2017-11-21 09:25:18 +08:00
|
|
|
-- Test index-only scans
|
|
|
|
SET enable_bitmapscan = false;
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT c FROM test_cube WHERE c <@ '(3000,1000),(0,0)' ORDER BY c;
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------------------------
|
|
|
|
Sort
|
|
|
|
Sort Key: c
|
|
|
|
-> Index Only Scan using test_cube_ix on test_cube
|
|
|
|
Index Cond: (c <@ '(3000, 1000),(0, 0)'::cube)
|
|
|
|
(4 rows)
|
|
|
|
|
|
|
|
SELECT c FROM test_cube WHERE c <@ '(3000,1000),(0,0)' ORDER BY c;
|
|
|
|
c
|
|
|
|
-------------------------
|
|
|
|
(337, 455),(240, 359)
|
|
|
|
(759, 187),(662, 163)
|
|
|
|
(1444, 403),(1346, 344)
|
|
|
|
(2424, 160),(2424, 81)
|
|
|
|
(4 rows)
|
|
|
|
|
|
|
|
RESET enable_bitmapscan;
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
-- Test kNN
|
|
|
|
INSERT INTO test_cube VALUES ('(1,1)'), ('(100000)'), ('(0, 100000)'); -- Some corner cases
|
|
|
|
SET enable_seqscan = false;
|
|
|
|
-- Test different metrics
|
2015-12-18 19:38:27 +08:00
|
|
|
SELECT *, c <-> '(100, 100),(500, 500)'::cube as dist FROM test_cube ORDER BY c <-> '(100, 100),(500, 500)'::cube LIMIT 5;
|
|
|
|
c | dist
|
|
|
|
-------------------------+------------------
|
|
|
|
(337, 455),(240, 359) | 0
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
(1, 1) | 140.007142674936
|
2015-12-18 19:38:27 +08:00
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(948, 1201),(907, 1156) | 772.000647668122
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT *, c <=> '(100, 100),(500, 500)'::cube as dist FROM test_cube ORDER BY c <=> '(100, 100),(500, 500)'::cube LIMIT 5;
|
|
|
|
c | dist
|
|
|
|
-------------------------+------
|
|
|
|
(337, 455),(240, 359) | 0
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
(1, 1) | 99
|
2015-12-18 19:38:27 +08:00
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(948, 1201),(907, 1156) | 656
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT *, c <#> '(100, 100),(500, 500)'::cube as dist FROM test_cube ORDER BY c <#> '(100, 100),(500, 500)'::cube LIMIT 5;
|
|
|
|
c | dist
|
|
|
|
-------------------------+------
|
|
|
|
(337, 455),(240, 359) | 0
|
|
|
|
(759, 187),(662, 163) | 162
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
(1, 1) | 198
|
2015-12-18 19:38:27 +08:00
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(369, 1457),(278, 1409) | 909
|
|
|
|
(5 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
-- Test sorting by coordinates
|
|
|
|
SELECT c~>1, c FROM test_cube ORDER BY c~>1 LIMIT 15; -- ascending by left bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (0, 100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
3 | (54, 38679),(3, 38602)
|
|
|
|
15 | (83, 10271),(15, 10265)
|
|
|
|
64 | (122, 46832),(64, 46762)
|
|
|
|
92 | (167, 17214),(92, 17184)
|
|
|
|
107 | (161, 24465),(107, 24374)
|
|
|
|
120 | (162, 26040),(120, 25963)
|
|
|
|
138 | (154, 4019),(138, 3990)
|
|
|
|
175 | (259, 1850),(175, 1820)
|
|
|
|
179 | (207, 40886),(179, 40879)
|
|
|
|
204 | (288, 49588),(204, 49571)
|
|
|
|
226 | (270, 32616),(226, 32607)
|
|
|
|
235 | (318, 31489),(235, 31404)
|
|
|
|
240 | (337, 455),(240, 359)
|
2015-12-18 19:38:27 +08:00
|
|
|
(15 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
SELECT c~>2, c FROM test_cube ORDER BY c~>2 LIMIT 15; -- ascending by right bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (0, 100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
54 | (54, 38679),(3, 38602)
|
|
|
|
83 | (83, 10271),(15, 10265)
|
|
|
|
122 | (122, 46832),(64, 46762)
|
|
|
|
154 | (154, 4019),(138, 3990)
|
|
|
|
161 | (161, 24465),(107, 24374)
|
|
|
|
162 | (162, 26040),(120, 25963)
|
|
|
|
167 | (167, 17214),(92, 17184)
|
|
|
|
207 | (207, 40886),(179, 40879)
|
|
|
|
259 | (259, 1850),(175, 1820)
|
|
|
|
270 | (270, 29508),(264, 29440)
|
|
|
|
270 | (270, 32616),(226, 32607)
|
|
|
|
288 | (288, 49588),(204, 49571)
|
|
|
|
318 | (318, 31489),(235, 31404)
|
2015-12-18 19:38:27 +08:00
|
|
|
(15 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
SELECT c~>3, c FROM test_cube ORDER BY c~>3 LIMIT 15; -- ascending by lower bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
6 | (30333, 50),(30273, 6)
|
|
|
|
43 | (43301, 75),(43227, 43)
|
|
|
|
51 | (19650, 142),(19630, 51)
|
|
|
|
81 | (2424, 160),(2424, 81)
|
|
|
|
108 | (3449, 171),(3354, 108)
|
|
|
|
109 | (18037, 155),(17941, 109)
|
|
|
|
114 | (28511, 208),(28479, 114)
|
|
|
|
118 | (19946, 217),(19941, 118)
|
|
|
|
139 | (16906, 191),(16816, 139)
|
|
|
|
163 | (759, 187),(662, 163)
|
|
|
|
181 | (22684, 266),(22656, 181)
|
|
|
|
213 | (24423, 255),(24360, 213)
|
|
|
|
222 | (45989, 249),(45910, 222)
|
2015-12-18 19:38:27 +08:00
|
|
|
(15 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
SELECT c~>4, c FROM test_cube ORDER BY c~>4 LIMIT 15; -- ascending by upper bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
50 | (30333, 50),(30273, 6)
|
|
|
|
75 | (43301, 75),(43227, 43)
|
|
|
|
142 | (19650, 142),(19630, 51)
|
|
|
|
155 | (18037, 155),(17941, 109)
|
|
|
|
160 | (2424, 160),(2424, 81)
|
|
|
|
171 | (3449, 171),(3354, 108)
|
|
|
|
187 | (759, 187),(662, 163)
|
|
|
|
191 | (16906, 191),(16816, 139)
|
|
|
|
208 | (28511, 208),(28479, 114)
|
|
|
|
217 | (19946, 217),(19941, 118)
|
|
|
|
249 | (45989, 249),(45910, 222)
|
|
|
|
255 | (24423, 255),(24360, 213)
|
|
|
|
266 | (22684, 266),(22656, 181)
|
2015-12-18 19:38:27 +08:00
|
|
|
(15 rows)
|
|
|
|
|
2018-01-11 19:49:36 +08:00
|
|
|
SELECT c~>(-1), c FROM test_cube ORDER BY c~>(-1) LIMIT 15; -- descending by left bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (100000)
|
|
|
|
-49951 | (50027, 49230),(49951, 49214)
|
|
|
|
-49937 | (49980, 35004),(49937, 34963)
|
|
|
|
-49927 | (49985, 6436),(49927, 6338)
|
|
|
|
-49908 | (49999, 27218),(49908, 27176)
|
|
|
|
-49905 | (49954, 1340),(49905, 1294)
|
|
|
|
-49902 | (49944, 25163),(49902, 25153)
|
|
|
|
-49898 | (49981, 34876),(49898, 34786)
|
|
|
|
-49897 | (49957, 43390),(49897, 43384)
|
|
|
|
-49848 | (49853, 18504),(49848, 18503)
|
|
|
|
-49818 | (49902, 41752),(49818, 41746)
|
|
|
|
-49810 | (49907, 30225),(49810, 30158)
|
|
|
|
-49808 | (49843, 5175),(49808, 5145)
|
|
|
|
-49805 | (49887, 24274),(49805, 24184)
|
|
|
|
-49798 | (49847, 7128),(49798, 7067)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>(-2), c FROM test_cube ORDER BY c~>(-2) LIMIT 15; -- descending by right bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (100000)
|
|
|
|
-50027 | (50027, 49230),(49951, 49214)
|
|
|
|
-49999 | (49999, 27218),(49908, 27176)
|
|
|
|
-49985 | (49985, 6436),(49927, 6338)
|
|
|
|
-49981 | (49981, 34876),(49898, 34786)
|
|
|
|
-49980 | (49980, 35004),(49937, 34963)
|
|
|
|
-49957 | (49957, 43390),(49897, 43384)
|
|
|
|
-49954 | (49954, 1340),(49905, 1294)
|
|
|
|
-49944 | (49944, 25163),(49902, 25153)
|
|
|
|
-49907 | (49907, 30225),(49810, 30158)
|
|
|
|
-49902 | (49902, 41752),(49818, 41746)
|
|
|
|
-49887 | (49887, 24274),(49805, 24184)
|
|
|
|
-49853 | (49853, 18504),(49848, 18503)
|
|
|
|
-49847 | (49847, 7128),(49798, 7067)
|
|
|
|
-49843 | (49843, 5175),(49808, 5145)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>(-3), c FROM test_cube ORDER BY c~>(-3) LIMIT 15; -- descending by lower bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (0, 100000)
|
|
|
|
-49992 | (30746, 50040),(30727, 49992)
|
|
|
|
-49987 | (36311, 50073),(36258, 49987)
|
|
|
|
-49934 | (3531, 49962),(3463, 49934)
|
|
|
|
-49915 | (17954, 49975),(17865, 49915)
|
|
|
|
-49914 | (2168, 50012),(2108, 49914)
|
|
|
|
-49913 | (31287, 49923),(31236, 49913)
|
|
|
|
-49885 | (21551, 49983),(21492, 49885)
|
|
|
|
-49878 | (43925, 49912),(43888, 49878)
|
|
|
|
-49849 | (19128, 49932),(19112, 49849)
|
|
|
|
-49844 | (38266, 49852),(38233, 49844)
|
|
|
|
-49836 | (14913, 49873),(14849, 49836)
|
|
|
|
-49834 | (37595, 49849),(37581, 49834)
|
|
|
|
-49830 | (46151, 49848),(46058, 49830)
|
|
|
|
-49818 | (29261, 49910),(29247, 49818)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>(-4), c FROM test_cube ORDER BY c~>(-4) LIMIT 15; -- descending by upper bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (0, 100000)
|
|
|
|
-50073 | (36311, 50073),(36258, 49987)
|
|
|
|
-50040 | (30746, 50040),(30727, 49992)
|
|
|
|
-50012 | (2168, 50012),(2108, 49914)
|
|
|
|
-49983 | (21551, 49983),(21492, 49885)
|
|
|
|
-49975 | (17954, 49975),(17865, 49915)
|
|
|
|
-49962 | (3531, 49962),(3463, 49934)
|
|
|
|
-49932 | (19128, 49932),(19112, 49849)
|
|
|
|
-49923 | (31287, 49923),(31236, 49913)
|
|
|
|
-49912 | (43925, 49912),(43888, 49878)
|
|
|
|
-49910 | (29261, 49910),(29247, 49818)
|
|
|
|
-49873 | (14913, 49873),(14849, 49836)
|
|
|
|
-49858 | (20007, 49858),(19921, 49778)
|
|
|
|
-49852 | (38266, 49852),(38233, 49844)
|
|
|
|
-49849 | (37595, 49849),(37581, 49834)
|
|
|
|
(15 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
-- Same queries with sequential scan (should give the same results as above)
|
|
|
|
RESET enable_seqscan;
|
|
|
|
SET enable_indexscan = OFF;
|
|
|
|
SELECT *, c <-> '(100, 100),(500, 500)'::cube as dist FROM test_cube ORDER BY c <-> '(100, 100),(500, 500)'::cube LIMIT 5;
|
|
|
|
c | dist
|
|
|
|
-------------------------+------------------
|
|
|
|
(337, 455),(240, 359) | 0
|
|
|
|
(1, 1) | 140.007142674936
|
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(948, 1201),(907, 1156) | 772.000647668122
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT *, c <=> '(100, 100),(500, 500)'::cube as dist FROM test_cube ORDER BY c <=> '(100, 100),(500, 500)'::cube LIMIT 5;
|
|
|
|
c | dist
|
|
|
|
-------------------------+------
|
|
|
|
(337, 455),(240, 359) | 0
|
|
|
|
(1, 1) | 99
|
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(948, 1201),(907, 1156) | 656
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT *, c <#> '(100, 100),(500, 500)'::cube as dist FROM test_cube ORDER BY c <#> '(100, 100),(500, 500)'::cube LIMIT 5;
|
|
|
|
c | dist
|
|
|
|
-------------------------+------
|
|
|
|
(337, 455),(240, 359) | 0
|
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(1, 1) | 198
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(369, 1457),(278, 1409) | 909
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT c~>1, c FROM test_cube ORDER BY c~>1 LIMIT 15; -- ascending by left bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (0, 100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
3 | (54, 38679),(3, 38602)
|
|
|
|
15 | (83, 10271),(15, 10265)
|
|
|
|
64 | (122, 46832),(64, 46762)
|
|
|
|
92 | (167, 17214),(92, 17184)
|
|
|
|
107 | (161, 24465),(107, 24374)
|
|
|
|
120 | (162, 26040),(120, 25963)
|
|
|
|
138 | (154, 4019),(138, 3990)
|
|
|
|
175 | (259, 1850),(175, 1820)
|
|
|
|
179 | (207, 40886),(179, 40879)
|
|
|
|
204 | (288, 49588),(204, 49571)
|
|
|
|
226 | (270, 32616),(226, 32607)
|
|
|
|
235 | (318, 31489),(235, 31404)
|
|
|
|
240 | (337, 455),(240, 359)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>2, c FROM test_cube ORDER BY c~>2 LIMIT 15; -- ascending by right bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (0, 100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
54 | (54, 38679),(3, 38602)
|
|
|
|
83 | (83, 10271),(15, 10265)
|
|
|
|
122 | (122, 46832),(64, 46762)
|
|
|
|
154 | (154, 4019),(138, 3990)
|
|
|
|
161 | (161, 24465),(107, 24374)
|
|
|
|
162 | (162, 26040),(120, 25963)
|
|
|
|
167 | (167, 17214),(92, 17184)
|
|
|
|
207 | (207, 40886),(179, 40879)
|
|
|
|
259 | (259, 1850),(175, 1820)
|
|
|
|
270 | (270, 29508),(264, 29440)
|
|
|
|
270 | (270, 32616),(226, 32607)
|
|
|
|
288 | (288, 49588),(204, 49571)
|
|
|
|
318 | (318, 31489),(235, 31404)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>3, c FROM test_cube ORDER BY c~>3 LIMIT 15; -- ascending by lower bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
6 | (30333, 50),(30273, 6)
|
|
|
|
43 | (43301, 75),(43227, 43)
|
|
|
|
51 | (19650, 142),(19630, 51)
|
|
|
|
81 | (2424, 160),(2424, 81)
|
|
|
|
108 | (3449, 171),(3354, 108)
|
|
|
|
109 | (18037, 155),(17941, 109)
|
|
|
|
114 | (28511, 208),(28479, 114)
|
|
|
|
118 | (19946, 217),(19941, 118)
|
|
|
|
139 | (16906, 191),(16816, 139)
|
|
|
|
163 | (759, 187),(662, 163)
|
|
|
|
181 | (22684, 266),(22656, 181)
|
|
|
|
213 | (24423, 255),(24360, 213)
|
|
|
|
222 | (45989, 249),(45910, 222)
|
2015-12-18 19:38:27 +08:00
|
|
|
(15 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
SELECT c~>4, c FROM test_cube ORDER BY c~>4 LIMIT 15; -- ascending by upper bound
|
|
|
|
?column? | c
|
|
|
|
----------+---------------------------
|
|
|
|
0 | (100000)
|
|
|
|
1 | (1, 1)
|
|
|
|
50 | (30333, 50),(30273, 6)
|
|
|
|
75 | (43301, 75),(43227, 43)
|
|
|
|
142 | (19650, 142),(19630, 51)
|
|
|
|
155 | (18037, 155),(17941, 109)
|
|
|
|
160 | (2424, 160),(2424, 81)
|
|
|
|
171 | (3449, 171),(3354, 108)
|
|
|
|
187 | (759, 187),(662, 163)
|
|
|
|
191 | (16906, 191),(16816, 139)
|
|
|
|
208 | (28511, 208),(28479, 114)
|
|
|
|
217 | (19946, 217),(19941, 118)
|
|
|
|
249 | (45989, 249),(45910, 222)
|
|
|
|
255 | (24423, 255),(24360, 213)
|
|
|
|
266 | (22684, 266),(22656, 181)
|
2015-12-18 19:38:27 +08:00
|
|
|
(15 rows)
|
|
|
|
|
2018-01-11 19:49:36 +08:00
|
|
|
SELECT c~>(-1), c FROM test_cube ORDER BY c~>(-1) LIMIT 15; -- descending by left bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (100000)
|
|
|
|
-49951 | (50027, 49230),(49951, 49214)
|
|
|
|
-49937 | (49980, 35004),(49937, 34963)
|
|
|
|
-49927 | (49985, 6436),(49927, 6338)
|
|
|
|
-49908 | (49999, 27218),(49908, 27176)
|
|
|
|
-49905 | (49954, 1340),(49905, 1294)
|
|
|
|
-49902 | (49944, 25163),(49902, 25153)
|
|
|
|
-49898 | (49981, 34876),(49898, 34786)
|
|
|
|
-49897 | (49957, 43390),(49897, 43384)
|
|
|
|
-49848 | (49853, 18504),(49848, 18503)
|
|
|
|
-49818 | (49902, 41752),(49818, 41746)
|
|
|
|
-49810 | (49907, 30225),(49810, 30158)
|
|
|
|
-49808 | (49843, 5175),(49808, 5145)
|
|
|
|
-49805 | (49887, 24274),(49805, 24184)
|
|
|
|
-49798 | (49847, 7128),(49798, 7067)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>(-2), c FROM test_cube ORDER BY c~>(-2) LIMIT 15; -- descending by right bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (100000)
|
|
|
|
-50027 | (50027, 49230),(49951, 49214)
|
|
|
|
-49999 | (49999, 27218),(49908, 27176)
|
|
|
|
-49985 | (49985, 6436),(49927, 6338)
|
|
|
|
-49981 | (49981, 34876),(49898, 34786)
|
|
|
|
-49980 | (49980, 35004),(49937, 34963)
|
|
|
|
-49957 | (49957, 43390),(49897, 43384)
|
|
|
|
-49954 | (49954, 1340),(49905, 1294)
|
|
|
|
-49944 | (49944, 25163),(49902, 25153)
|
|
|
|
-49907 | (49907, 30225),(49810, 30158)
|
|
|
|
-49902 | (49902, 41752),(49818, 41746)
|
|
|
|
-49887 | (49887, 24274),(49805, 24184)
|
|
|
|
-49853 | (49853, 18504),(49848, 18503)
|
|
|
|
-49847 | (49847, 7128),(49798, 7067)
|
|
|
|
-49843 | (49843, 5175),(49808, 5145)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>(-3), c FROM test_cube ORDER BY c~>(-3) LIMIT 15; -- descending by lower bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (0, 100000)
|
|
|
|
-49992 | (30746, 50040),(30727, 49992)
|
|
|
|
-49987 | (36311, 50073),(36258, 49987)
|
|
|
|
-49934 | (3531, 49962),(3463, 49934)
|
|
|
|
-49915 | (17954, 49975),(17865, 49915)
|
|
|
|
-49914 | (2168, 50012),(2108, 49914)
|
|
|
|
-49913 | (31287, 49923),(31236, 49913)
|
|
|
|
-49885 | (21551, 49983),(21492, 49885)
|
|
|
|
-49878 | (43925, 49912),(43888, 49878)
|
|
|
|
-49849 | (19128, 49932),(19112, 49849)
|
|
|
|
-49844 | (38266, 49852),(38233, 49844)
|
|
|
|
-49836 | (14913, 49873),(14849, 49836)
|
|
|
|
-49834 | (37595, 49849),(37581, 49834)
|
|
|
|
-49830 | (46151, 49848),(46058, 49830)
|
|
|
|
-49818 | (29261, 49910),(29247, 49818)
|
|
|
|
(15 rows)
|
|
|
|
|
|
|
|
SELECT c~>(-4), c FROM test_cube ORDER BY c~>(-4) LIMIT 15; -- descending by upper bound
|
|
|
|
?column? | c
|
|
|
|
----------+-------------------------------
|
|
|
|
-100000 | (0, 100000)
|
|
|
|
-50073 | (36311, 50073),(36258, 49987)
|
|
|
|
-50040 | (30746, 50040),(30727, 49992)
|
|
|
|
-50012 | (2168, 50012),(2108, 49914)
|
|
|
|
-49983 | (21551, 49983),(21492, 49885)
|
|
|
|
-49975 | (17954, 49975),(17865, 49915)
|
|
|
|
-49962 | (3531, 49962),(3463, 49934)
|
|
|
|
-49932 | (19128, 49932),(19112, 49849)
|
|
|
|
-49923 | (31287, 49923),(31236, 49913)
|
|
|
|
-49912 | (43925, 49912),(43888, 49878)
|
|
|
|
-49910 | (29261, 49910),(29247, 49818)
|
|
|
|
-49873 | (14913, 49873),(14849, 49836)
|
|
|
|
-49858 | (20007, 49858),(19921, 49778)
|
|
|
|
-49852 | (38266, 49852),(38233, 49844)
|
|
|
|
-49849 | (37595, 49849),(37581, 49834)
|
|
|
|
(15 rows)
|
|
|
|
|
Fix behavior of ~> (cube, int) operator
~> (cube, int) operator was especially designed for knn-gist search.
However, it appears that knn-gist search can't work correctly with current
behavior of this operator when dataset contains cubes of variable
dimensionality. In this case, the same value of second operator argument
can point to different dimension depending on dimensionality of particular cube.
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't
work correctly for it.
This patch changes behavior of ~> (cube, int) operator by introducing dimension
numbering where value of second argument unambiguously identifies number of
dimension. With new behavior, this operator can be correctly supported by
knn-gist. Relevant changes to cube operator class are also included.
Backpatch to v9.6 where operator was introduced.
Since behavior of ~> (cube, int) operator is changed, depending entities
must be refreshed after upgrade. Such as, expression indexes using this
operator must be reindexed, materialized views must be rebuilt, stored
procedures and client code must be revised to correctly use new behavior.
That should be mentioned in release notes.
Noticed by: Tomas Vondra
Author: Alexander Korotkov
Reviewed by: Tomas Vondra, Andrey Borodin
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com
2018-01-11 19:41:14 +08:00
|
|
|
RESET enable_indexscan;
|