2000-12-11 21:39:15 +01:00
|
|
|
--
|
|
|
|
-- Test cube datatype
|
|
|
|
--
|
2011-02-14 02:06:41 +01:00
|
|
|
CREATE EXTENSION cube;
|
2016-11-29 21:05:22 +01: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)
|
|
|
|
|
2000-12-11 21:39:15 +01: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;
|
2002-08-30 01:03:58 +02:00
|
|
|
cube
|
|
|
|
--------
|
|
|
|
(-0.1)
|
|
|
|
(1 row)
|
2000-12-11 21:39:15 +01:00
|
|
|
|
|
|
|
SELECT '1.0'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(1)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-1.0'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
(-1)
|
|
|
|
(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 17:38:33 +02:00
|
|
|
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)
|
2000-12-11 21:39:15 +01:00
|
|
|
(1 row)
|
|
|
|
|
2002-08-30 01:03:58 +02:00
|
|
|
SELECT '.1234567890123456'::cube AS cube;
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
cube
|
|
|
|
----------------------
|
|
|
|
(0.1234567890123456)
|
2002-08-30 01:03:58 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '+.1234567890123456'::cube AS cube;
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
cube
|
|
|
|
----------------------
|
|
|
|
(0.1234567890123456)
|
2002-08-30 01:03:58 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '-.1234567890123456'::cube AS cube;
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
cube
|
|
|
|
-----------------------
|
|
|
|
(-0.1234567890123456)
|
2002-08-30 01:03:58 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-12-11 21:39:15 +01:00
|
|
|
-- 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 17:38:33 +02:00
|
|
|
SELECT '()'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
()
|
|
|
|
(1 row)
|
|
|
|
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
SELECT '(),()'::cube AS cube;
|
|
|
|
cube
|
|
|
|
------
|
|
|
|
()
|
|
|
|
(1 row)
|
|
|
|
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT ''::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at end of input
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT 'ABC'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "A"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[]'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "]"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02: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 17:38:33 +02:00
|
|
|
DETAIL: syntax error at or near "]"
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1)]'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "]"
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1),]'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "]"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1),2]'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "2"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1),(2),(3)]'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ","
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1,'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at end of input
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1,2,'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at end of input
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1,,2'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ","
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,)'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ")"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,2,)'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ")"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,,2)'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ","
|
2000-12-11 21:39:15 +01:00
|
|
|
-- 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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1),(2)],'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ","
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1,2,3),(2,3)]'::cube AS cube;
|
|
|
|
^
|
2006-03-01 22:09:32 +01:00
|
|
|
DETAIL: Different point dimensions in (1,2,3) and (2,3).
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '[(1,2),(1,2,3)]'::cube AS cube;
|
|
|
|
^
|
2006-03-01 22:09:32 +01:00
|
|
|
DETAIL: Different point dimensions in (1,2) and (1,2,3).
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1),(2),'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near ","
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,2,3),(2,3)'::cube AS cube;
|
|
|
|
^
|
2006-03-01 22:09:32 +01:00
|
|
|
DETAIL: Different point dimensions in (1,2,3) and (2,3).
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,2),(1,2,3)'::cube AS cube;
|
|
|
|
^
|
2006-03-01 22:09:32 +01:00
|
|
|
DETAIL: Different point dimensions in (1,2) and (1,2,3).
|
2000-12-11 21:39:15 +01: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,2,3)ab'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "a"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,2,3)a'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "a"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '(1,2)('::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "("
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1,2ab'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "a"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1 e7'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "e"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1,2a'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02:00
|
|
|
DETAIL: syntax error at or near "a"
|
2000-12-11 21:39:15 +01:00
|
|
|
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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT '1..2'::cube AS cube;
|
|
|
|
^
|
2003-09-14 03:52:25 +02: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 17:38:33 +02: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;
|
|
|
|
^
|
2003-02-13 06:26:50 +01: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-26 01:23:45 +02: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-23 21:27:50 +01:00
|
|
|
SELECT cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[3,2,1,1]);
|
2006-07-26 01:23:45 +02:00
|
|
|
cube_subset
|
|
|
|
---------------------------
|
|
|
|
(5, 3, 1, 1),(8, 7, 6, 6)
|
|
|
|
(1 row)
|
|
|
|
|
2013-10-22 08:28:30 +02: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-23 21:27:50 +01:00
|
|
|
SELECT cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[4,0]);
|
2006-07-26 01:23:45 +02:00
|
|
|
ERROR: Index out of bounds
|
2013-10-22 08:28:30 +02:00
|
|
|
SELECT cube_subset(cube('(6,7,8),(6,7,8)'), ARRAY[4,0]);
|
|
|
|
ERROR: Index out of bounds
|
2018-08-30 13:18:53 +02:00
|
|
|
-- test for limits: this should pass
|
|
|
|
SELECT cube_subset(cube('(6,7,8),(6,7,8)'), array(SELECT 1 as a FROM generate_series(1,100)));
|
|
|
|
cube_subset
|
|
|
|
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
(6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- and this should fail
|
|
|
|
SELECT cube_subset(cube('(6,7,8),(6,7,8)'), array(SELECT 1 as a FROM generate_series(1,101)));
|
|
|
|
ERROR: array is too long
|
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
2013-10-22 08:28:30 +02:00
|
|
|
--
|
|
|
|
-- 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)
|
|
|
|
|
2002-09-12 02:26:00 +02:00
|
|
|
--
|
|
|
|
-- Testing limit of CUBE_MAX_DIM dimensions check in cube_in.
|
|
|
|
--
|
2018-08-30 13:18:53 +02:00
|
|
|
-- create too big cube from literal
|
2002-09-12 02:26:00 +02: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)'::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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02: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-01 22:09:32 +01:00
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
2002-09-12 02:26:00 +02: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 17:38:33 +02:00
|
|
|
ERROR: invalid input syntax for cube
|
2008-09-01 22:42:46 +02: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-01 22:09:32 +01:00
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
2018-08-30 13:18:53 +02:00
|
|
|
-- from an array
|
|
|
|
select cube(array(SELECT 0 as a FROM generate_series(1,101)));
|
|
|
|
ERROR: array is too long
|
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
|
|
|
select cube(array(SELECT 0 as a FROM generate_series(1,101)),array(SELECT 0 as a FROM generate_series(1,101)));
|
|
|
|
ERROR: can't extend cube
|
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
|
|
|
-- extend cube beyond limit
|
|
|
|
-- this should work
|
|
|
|
select cube(array(SELECT 0 as a FROM generate_series(1,100)));
|
|
|
|
cube
|
|
|
|
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select cube(array(SELECT 0 as a FROM generate_series(1,100)),array(SELECT 0 as a FROM generate_series(1,100)));
|
|
|
|
cube
|
|
|
|
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- this should fail
|
|
|
|
select cube(cube(array(SELECT 0 as a FROM generate_series(1,100))), 0);
|
|
|
|
ERROR: can't extend cube
|
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
|
|
|
select cube(cube(array(SELECT 0 as a FROM generate_series(1,100)),array(SELECT 0 as a FROM generate_series(1,100))), 0, 0);
|
|
|
|
ERROR: can't extend cube
|
|
|
|
DETAIL: A cube cannot have more than 100 dimensions.
|
2000-12-11 21:39:15 +01: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
|
|
|
|
------
|
2003-09-14 03:52:25 +02:00
|
|
|
f
|
2000-12-11 21:39:15 +01:00
|
|
|
(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-10 19:36:52 +02:00
|
|
|
SELECT '0'::cube <@ '0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0,0'::cube <@ '0,0,0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0'::cube <@ '0,0,1'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0,0'::cube <@ '0,0,1'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '1,0,0'::cube <@ '0,0,1'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube <@ '(1,0,0),(0,0,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube <@ '(-1,-1,-1),(1,1,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube <@ '(-1,-1,-1,-1),(1,1,1,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0'::cube <@ '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '1'::cube <@ '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '-1'::cube <@ '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube <@ '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube <@ '(-1,-1),(1,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-2),(1)'::cube <@ '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-2),(1)'::cube <@ '(-1,-1),(1,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- "contains" (the left operand is the cube that entirely encloses the
|
|
|
|
-- right operand)
|
|
|
|
--
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0'::cube @> '0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0,0'::cube @> '0,0,0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0,1'::cube @> '0,0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0,1'::cube @> '0,0,0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '0,0,1'::cube @> '1,0,0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(1,0,0),(0,0,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1,-1,-1),(1,1,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1,-1,-1,-1),(1,1,1,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube @> '0'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube @> '1'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube @> '-1'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube @> '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1,-1),(1,1)'::cube @> '(-1),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1),(1)'::cube @> '(-2),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT '(-1,-1),(1,1)'::cube @> '(-2),(1)'::cube AS bool;
|
2000-12-11 21:39:15 +01:00
|
|
|
bool
|
|
|
|
------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2002-08-30 01:03:58 +02:00
|
|
|
-- 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)
|
|
|
|
|
2013-10-22 08:28:30 +02: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);
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
cube_distance
|
|
|
|
--------------------
|
|
|
|
140.76221083799445
|
2013-10-22 08:28:30 +02:00
|
|
|
(1 row)
|
|
|
|
|
2002-08-30 01:03:58 +02:00
|
|
|
-- Test of cube function (text to cube)
|
|
|
|
--
|
2007-06-05 23:31:09 +02:00
|
|
|
SELECT cube('(1,1.2)'::text);
|
2002-08-30 01:03:58 +02: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)
|
|
|
|
|
2013-10-22 08:28:30 +02: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 10:33:58 +01:00
|
|
|
-- Test of cube_ll_coord function (retrieves LL coordinate values)
|
2002-08-30 01:03:58 +02: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)
|
|
|
|
|
2013-10-22 08:28:30 +02: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 10:33:58 +01:00
|
|
|
-- Test of cube_ur_coord function (retrieves UR coordinate values)
|
2002-08-30 01:03:58 +02: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)
|
|
|
|
|
2013-10-22 08:28:30 +02: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)
|
|
|
|
|
2002-08-30 01:03:58 +02: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)
|
|
|
|
|
2002-09-12 02:26:00 +02:00
|
|
|
SELECT cube_enlarge('(2),(-2)'::cube, 0, 4);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(-2),(2)
|
|
|
|
(1 row)
|
|
|
|
|
2002-08-30 01:03:58 +02:00
|
|
|
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)
|
|
|
|
|
2002-09-12 02:26:00 +02:00
|
|
|
SELECT cube_enlarge('(2),(-2)'::cube, 1, 4);
|
|
|
|
cube_enlarge
|
|
|
|
-------------------------------
|
|
|
|
(-3, -1, -1, -1),(3, 1, 1, 1)
|
|
|
|
(1 row)
|
|
|
|
|
2002-08-30 01:03:58 +02:00
|
|
|
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)
|
|
|
|
|
2002-09-12 02:26:00 +02:00
|
|
|
SELECT cube_enlarge('(2),(-2)'::cube, -1, 4);
|
|
|
|
cube_enlarge
|
|
|
|
--------------
|
|
|
|
(-1),(1)
|
|
|
|
(1 row)
|
|
|
|
|
2002-08-30 01:03:58 +02:00
|
|
|
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)
|
|
|
|
|
2013-10-22 08:28:30 +02: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)
|
|
|
|
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
-- Test of distances (euclidean distance may not be bit-exact)
|
2015-12-18 12:38:27 +01:00
|
|
|
--
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
SET extra_float_digits = 0;
|
2015-12-18 12:38:27 +01:00
|
|
|
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)
|
|
|
|
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
RESET extra_float_digits;
|
2015-12-18 12:38:27 +01:00
|
|
|
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-28 20:39:09 +01:00
|
|
|
ERROR: cube index 0 is out of bounds
|
2015-12-18 12:38:27 +01:00
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->7;
|
2015-12-28 20:39:09 +01:00
|
|
|
ERROR: cube index 7 is out of bounds
|
2015-12-18 12:38:27 +01:00
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->-1;
|
2015-12-28 20:39:09 +01:00
|
|
|
ERROR: cube index -1 is out of bounds
|
2015-12-18 12:38:27 +01:00
|
|
|
SELECT cube(array[10,20,30], array[40,50,60])->-6;
|
2015-12-28 20:39:09 +01:00
|
|
|
ERROR: cube index -6 is out of bounds
|
2015-12-18 12:38:27 +01: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-28 20:39:09 +01:00
|
|
|
ERROR: cube index -6 is out of bounds
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
40
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
40
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
20
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
20
|
2015-12-18 12:38:27 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>0;
|
2018-01-11 12:49:36 +01:00
|
|
|
ERROR: zero cube index is not defined
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
50
|
2015-12-18 12:38:27 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT cube(array[40,50,60], array[10,20,30])~>(-1);
|
2018-01-11 12:49:36 +01:00
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
-10
|
|
|
|
(1 row)
|
|
|
|
|
2000-12-11 21:39:15 +01:00
|
|
|
-- Load some example data and build the index
|
2010-11-23 21:27:50 +01:00
|
|
|
--
|
2000-12-11 21:39:15 +01: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-23 21:27:50 +01:00
|
|
|
SELECT * FROM test_cube WHERE c && '(3000,1000),(0,0)' ORDER BY c;
|
2000-12-11 21:39:15 +01:00
|
|
|
c
|
|
|
|
--------------------------
|
2006-07-26 01:23:45 +02:00
|
|
|
(337, 455),(240, 359)
|
|
|
|
(759, 187),(662, 163)
|
2006-07-27 23:55:09 +02:00
|
|
|
(1444, 403),(1346, 344)
|
|
|
|
(1594, 1043),(1517, 971)
|
2006-07-26 01:23:45 +02:00
|
|
|
(2424, 160),(2424, 81)
|
2000-12-11 21:39:15 +01:00
|
|
|
(5 rows)
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
-- Test sorting
|
|
|
|
SELECT * FROM test_cube WHERE c && '(3000,1000),(0,0)' GROUP BY c ORDER BY c;
|
2000-12-11 21:39:15 +01:00
|
|
|
c
|
|
|
|
--------------------------
|
|
|
|
(337, 455),(240, 359)
|
2006-07-26 01:23:45 +02:00
|
|
|
(759, 187),(662, 163)
|
2006-07-27 23:55:09 +02:00
|
|
|
(1444, 403),(1346, 344)
|
|
|
|
(1594, 1043),(1517, 971)
|
2000-12-11 21:39:15 +01:00
|
|
|
(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 02:25:18 +01: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 12:41:14 +01:00
|
|
|
-- Test kNN
|
|
|
|
INSERT INTO test_cube VALUES ('(1,1)'), ('(100000)'), ('(0, 100000)'); -- Some corner cases
|
|
|
|
SET enable_seqscan = false;
|
|
|
|
-- Test different metrics
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
SET extra_float_digits = 0;
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
(1, 1) | 140.007142674936
|
2015-12-18 12:38:27 +01:00
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(948, 1201),(907, 1156) | 772.000647668122
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(5 rows)
|
|
|
|
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
RESET extra_float_digits;
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
(1, 1) | 99
|
2015-12-18 12:38:27 +01: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 12:41:14 +01:00
|
|
|
(1, 1) | 198
|
2015-12-18 12:38:27 +01: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 12:41:14 +01: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 12:38:27 +01: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 12:41:14 +01: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 12:38:27 +01: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 12:41:14 +01: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 12:38:27 +01: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 12:41:14 +01: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 12:38:27 +01:00
|
|
|
(15 rows)
|
|
|
|
|
2018-01-11 12:49:36 +01: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 12:41:14 +01:00
|
|
|
-- Same queries with sequential scan (should give the same results as above)
|
|
|
|
RESET enable_seqscan;
|
|
|
|
SET enable_indexscan = OFF;
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
SET extra_float_digits = 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 12:41:14 +01: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
|
|
|
|
(1, 1) | 140.007142674936
|
|
|
|
(759, 187),(662, 163) | 162
|
|
|
|
(948, 1201),(907, 1156) | 772.000647668122
|
|
|
|
(1444, 403),(1346, 344) | 846
|
|
|
|
(5 rows)
|
|
|
|
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
RESET extra_float_digits;
|
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 12:41:14 +01: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
|
|
|
|
(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 12:38:27 +01: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 12:41:14 +01: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 12:38:27 +01:00
|
|
|
(15 rows)
|
|
|
|
|
2018-01-11 12:49:36 +01: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 12:41:14 +01:00
|
|
|
RESET enable_indexscan;
|