2000-12-12 04:40:33 +08:00
--
-- Test seg datatype
--
2011-02-14 09:06:41 +08:00
CREATE EXTENSION seg;
2016-11-30 04:05:22 +08:00
-- Check whether any of our opclasses fail amvalidate
SELECT amname, opcname
FROM pg_opclass opc LEFT JOIN pg_am am ON am.oid = opcmethod
WHERE opc.oid >= 16384 AND NOT amvalidate(opc.oid);
amname | opcname
--------+---------
(0 rows)
2000-12-12 04:40:33 +08:00
--
-- testing the input and output functions
--
-- Any number
SELECT '1'::seg AS seg;
seg
-----
1
(1 row)
SELECT '-1'::seg AS seg;
seg
-----
-1
(1 row)
SELECT '1.0'::seg AS seg;
seg
-----
1.0
(1 row)
SELECT '-1.0'::seg AS seg;
seg
------
-1.0
(1 row)
SELECT '1e7'::seg AS seg;
seg
-------
1e+07
(1 row)
SELECT '-1e7'::seg AS seg;
seg
--------
-1e+07
(1 row)
SELECT '1.0e7'::seg AS seg;
seg
---------
1.0e+07
(1 row)
SELECT '-1.0e7'::seg AS seg;
seg
----------
-1.0e+07
(1 row)
SELECT '1e+7'::seg AS seg;
seg
-------
1e+07
(1 row)
SELECT '-1e+7'::seg AS seg;
seg
--------
-1e+07
(1 row)
SELECT '1.0e+7'::seg AS seg;
seg
---------
1.0e+07
(1 row)
SELECT '-1.0e+7'::seg AS seg;
seg
----------
-1.0e+07
(1 row)
SELECT '1e-7'::seg AS seg;
seg
-------
1e-07
(1 row)
SELECT '-1e-7'::seg AS seg;
seg
--------
-1e-07
(1 row)
SELECT '1.0e-7'::seg AS seg;
seg
---------
1.0e-07
(1 row)
SELECT '-1.0e-7'::seg AS seg;
seg
----------
-1.0e-07
(1 row)
SELECT '2e-6'::seg AS seg;
seg
-------
2e-06
(1 row)
SELECT '2e-5'::seg AS seg;
seg
-------
2e-05
(1 row)
SELECT '2e-4'::seg AS seg;
seg
--------
0.0002
(1 row)
SELECT '2e-3'::seg AS seg;
seg
-------
0.002
(1 row)
SELECT '2e-2'::seg AS seg;
seg
------
0.02
(1 row)
SELECT '2e-1'::seg AS seg;
seg
-----
0.2
(1 row)
SELECT '2e-0'::seg AS seg;
seg
-----
2
(1 row)
SELECT '2e+0'::seg AS seg;
seg
-----
2
(1 row)
SELECT '2e+1'::seg AS seg;
seg
-----
2e1
(1 row)
SELECT '2e+2'::seg AS seg;
seg
-----
2e2
(1 row)
SELECT '2e+3'::seg AS seg;
seg
-----
2e3
(1 row)
SELECT '2e+4'::seg AS seg;
seg
-----
2e4
(1 row)
SELECT '2e+5'::seg AS seg;
seg
-------
2e+05
(1 row)
SELECT '2e+6'::seg AS seg;
seg
-------
2e+06
(1 row)
-- Significant digits preserved
SELECT '1'::seg AS seg;
seg
-----
1
(1 row)
SELECT '1.0'::seg AS seg;
seg
-----
1.0
(1 row)
SELECT '1.00'::seg AS seg;
seg
------
1.00
(1 row)
SELECT '1.000'::seg AS seg;
seg
-------
1.000
(1 row)
SELECT '1.0000'::seg AS seg;
seg
--------
1.0000
(1 row)
SELECT '1.00000'::seg AS seg;
seg
---------
1.00000
(1 row)
SELECT '1.000000'::seg AS seg;
seg
---------
1.00000
(1 row)
SELECT '0.000000120'::seg AS seg;
seg
----------
1.20e-07
(1 row)
SELECT '3.400e5'::seg AS seg;
seg
-----------
3.400e+05
(1 row)
-- Digits truncated
SELECT '12.34567890123456'::seg AS seg;
seg
---------
12.3457
(1 row)
2022-12-22 06:51:50 +08:00
-- Same, with a very long input
SELECT '12.3456789012345600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'::seg AS seg;
seg
---------
12.3457
(1 row)
2000-12-12 04:40:33 +08:00
-- Numbers with certainty indicators
SELECT '~6.5'::seg AS seg;
seg
------
~6.5
(1 row)
SELECT '<6.5'::seg AS seg;
seg
------
<6.5
(1 row)
SELECT '>6.5'::seg AS seg;
seg
------
>6.5
(1 row)
SELECT '~ 6.5'::seg AS seg;
seg
------
~6.5
(1 row)
SELECT '< 6.5'::seg AS seg;
seg
------
<6.5
(1 row)
SELECT '> 6.5'::seg AS seg;
seg
------
>6.5
(1 row)
-- Open intervals
SELECT '0..'::seg AS seg;
seg
------
0 ..
(1 row)
SELECT '0...'::seg AS seg;
seg
------
0 ..
(1 row)
SELECT '0 ..'::seg AS seg;
seg
------
0 ..
(1 row)
SELECT '0 ...'::seg AS seg;
seg
------
0 ..
(1 row)
SELECT '..0'::seg AS seg;
seg
------
.. 0
(1 row)
SELECT '...0'::seg AS seg;
seg
------
.. 0
(1 row)
SELECT '.. 0'::seg AS seg;
seg
------
.. 0
(1 row)
SELECT '... 0'::seg AS seg;
seg
------
.. 0
(1 row)
-- Finite intervals
SELECT '0 .. 1'::seg AS seg;
seg
--------
0 .. 1
(1 row)
SELECT '-1 .. 0'::seg AS seg;
seg
---------
-1 .. 0
(1 row)
SELECT '-1 .. 1'::seg AS seg;
seg
---------
-1 .. 1
(1 row)
-- (+/-) intervals
SELECT '0(+-)1'::seg AS seg;
seg
---------
-1 .. 1
(1 row)
SELECT '0(+-)1.0'::seg AS seg;
seg
-------------
-1.0 .. 1.0
(1 row)
SELECT '1.0(+-)0.005'::seg AS seg;
seg
----------------
0.995 .. 1.005
(1 row)
SELECT '101(+-)1'::seg AS seg;
seg
------------------
1.00e2 .. 1.02e2
(1 row)
-- incorrect number of significant digits in 99.0:
SELECT '100(+-)1'::seg AS seg;
seg
----------------
99.0 .. 1.01e2
(1 row)
-- invalid input
SELECT ''::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT ''::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at end of input
2000-12-12 04:40:33 +08:00
SELECT 'ABC'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT 'ABC'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near "A"
2000-12-12 04:40:33 +08:00
SELECT '1ABC'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '1ABC'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near "A"
2000-12-12 04:40:33 +08:00
SELECT '1.'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '1.'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near "."
2000-12-12 04:40:33 +08:00
SELECT '1.....'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '1.....'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near ".."
2000-12-12 04:40:33 +08:00
SELECT '.1'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '.1'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near "."
2000-12-12 04:40:33 +08:00
SELECT '1..2.'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '1..2.'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near "."
2000-12-12 04:40:33 +08:00
SELECT '1 e7'::seg AS seg;
2003-09-14 10:18:49 +08:00
ERROR: bad seg representation
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '1 e7'::seg AS seg;
^
2003-09-14 10:18:49 +08:00
DETAIL: syntax error at or near "e"
2000-12-12 04:40:33 +08:00
SELECT '1e700'::seg AS seg;
2004-10-25 05:47:07 +08:00
ERROR: "1e700" is out of range for type real
2008-09-02 04:42:46 +08:00
LINE 1: SELECT '1e700'::seg AS seg;
^
2000-12-12 04:40:33 +08:00
--
-- testing the operators
--
-- equality/inequality:
--
SELECT '24 .. 33.20'::seg = '24 .. 33.20'::seg AS bool;
bool
------
t
(1 row)
SELECT '24 .. 33.20'::seg = '24 .. 33.21'::seg AS bool;
bool
------
f
(1 row)
SELECT '24 .. 33.20'::seg != '24 .. 33.20'::seg AS bool;
bool
------
f
(1 row)
SELECT '24 .. 33.20'::seg != '24 .. 33.21'::seg AS bool;
bool
------
t
(1 row)
-- overlap
--
SELECT '1'::seg && '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '1'::seg && '2'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 ..'::seg && '0 ..'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg && '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '..0'::seg && '0..'::seg AS bool;
bool
------
t
(1 row)
SELECT '-1 .. 0.1'::seg && '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '-1 .. 0'::seg && '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '-1 .. -0.0001'::seg && '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 ..'::seg && '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg && '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg && '2'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 2'::seg && '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '1'::seg && '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '2'::seg && '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg && '0 .. 2'::seg AS bool;
bool
------
t
(1 row)
-- overlap on the left
--
SELECT '1'::seg &< '0'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg &< '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '1'::seg &< '2'::seg AS bool;
bool
------
2005-06-27 08:48:07 +08:00
t
2000-12-12 04:40:33 +08:00
(1 row)
SELECT '0 .. 1'::seg &< '0'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg &< '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg &< '2'::seg AS bool;
bool
------
2005-06-27 08:48:07 +08:00
t
2000-12-12 04:40:33 +08:00
(1 row)
SELECT '0 .. 1'::seg &< '0 .. 0.5'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg &< '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg &< '0 .. 2'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg &< '1 .. 2'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg &< '2 .. 3'::seg AS bool;
bool
------
2005-06-27 08:48:07 +08:00
t
2000-12-12 04:40:33 +08:00
(1 row)
-- overlap on the right
--
SELECT '0'::seg &> '1'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg &> '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '2'::seg &> '1'::seg AS bool;
bool
------
2005-06-27 08:48:07 +08:00
t
2000-12-12 04:40:33 +08:00
(1 row)
SELECT '0'::seg &> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '1'::seg &> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '2'::seg &> '0 .. 1'::seg AS bool;
bool
------
2005-06-27 08:48:07 +08:00
t
2000-12-12 04:40:33 +08:00
(1 row)
SELECT '0 .. 0.5'::seg &> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg &> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 2'::seg &> '0 .. 2'::seg AS bool;
bool
------
t
(1 row)
SELECT '1 .. 2'::seg &> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '2 .. 3'::seg &> '0 .. 1'::seg AS bool;
bool
------
2005-06-27 08:48:07 +08:00
t
2000-12-12 04:40:33 +08:00
(1 row)
-- left
--
SELECT '1'::seg << '0'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg << '1'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg << '2'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg << '0'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg << '1'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg << '2'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 1'::seg << '0 .. 0.5'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg << '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg << '0 .. 2'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg << '1 .. 2'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg << '2 .. 3'::seg AS bool;
bool
------
t
(1 row)
-- right
--
SELECT '0'::seg >> '1'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg >> '1'::seg AS bool;
bool
------
f
(1 row)
SELECT '2'::seg >> '1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0'::seg >> '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '1'::seg >> '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '2'::seg >> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
SELECT '0 .. 0.5'::seg >> '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 1'::seg >> '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '0 .. 2'::seg >> '0 .. 2'::seg AS bool;
bool
------
f
(1 row)
SELECT '1 .. 2'::seg >> '0 .. 1'::seg AS bool;
bool
------
f
(1 row)
SELECT '2 .. 3'::seg >> '0 .. 1'::seg AS bool;
bool
------
t
(1 row)
-- "contained in" (the left value belongs within the interval specified in the right value):
--
2006-09-11 01:36:52 +08:00
SELECT '0'::seg <@ '0'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '0'::seg <@ '0 ..'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '0'::seg <@ '.. 0'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '0'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '0'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '-1'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '1'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '-1 .. 1'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
-- "contains" (the left value contains the interval specified in the right value):
--
2006-09-11 01:36:52 +08:00
SELECT '0'::seg @> '0'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '0 .. '::seg <@ '0'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
f
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '.. 0'::seg <@ '0'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
f
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '-1 .. 1'::seg <@ '0'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
f
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '0'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '-1'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
2006-09-11 01:36:52 +08:00
SELECT '1'::seg <@ '-1 .. 1'::seg AS bool;
2000-12-12 04:40:33 +08:00
bool
------
t
(1 row)
-- Load some example data and build the index
2010-11-24 04:27:50 +08:00
--
2000-12-12 04:40:33 +08:00
CREATE TABLE test_seg (s seg);
\copy test_seg from 'data/test_seg.data'
CREATE INDEX test_seg_ix ON test_seg USING gist (s);
2021-06-08 02:52:42 +08:00
SET enable_indexscan = false;
Support index-only scans in contrib/cube and contrib/seg GiST indexes.
To do this, we only have to remove the compress and decompress support
functions, which have never done anything more than detoasting.
In the wake of commit d3a4f89d8, this results in automatically enabling
index-only scans, since the core code will now know that the stored
representation is the same as the original data (up to detoasting).
The only exciting part of this is that ALTER OPERATOR FAMILY lacks
a way to drop a support function that was declared as being part of
an opclass rather than being loose in the family. For the moment,
we'll hack our way to a solution with a manual update of the pg_depend
entry type, which is what distinguishes the two cases. Perhaps
someday it'll be worth providing a cleaner way to do that, but for
now it seems like a very niche problem.
Note that the underlying C functions remain, to support use of the shared
libraries with older versions of the modules' SQL declarations. Someday
we may be able to remove them, but not soon.
Andrey Borodin, reviewed by me
Discussion: https://postgr.es/m/D0F53A05-4F4A-4DEC-8339-3C069FA0EE11@yandex-team.ru
2017-11-21 09:25:18 +08:00
EXPLAIN (COSTS OFF)
SELECT count(*) FROM test_seg WHERE s @> '11..11.3';
QUERY PLAN
-------------------------------------------------------
Aggregate
-> Bitmap Heap Scan on test_seg
Recheck Cond: (s @> '1.1e1 .. 11.3'::seg)
-> Bitmap Index Scan on test_seg_ix
Index Cond: (s @> '1.1e1 .. 11.3'::seg)
(5 rows)
SELECT count(*) FROM test_seg WHERE s @> '11..11.3';
count
-------
143
(1 row)
2021-06-08 02:52:42 +08:00
RESET enable_indexscan;
Support index-only scans in contrib/cube and contrib/seg GiST indexes.
To do this, we only have to remove the compress and decompress support
functions, which have never done anything more than detoasting.
In the wake of commit d3a4f89d8, this results in automatically enabling
index-only scans, since the core code will now know that the stored
representation is the same as the original data (up to detoasting).
The only exciting part of this is that ALTER OPERATOR FAMILY lacks
a way to drop a support function that was declared as being part of
an opclass rather than being loose in the family. For the moment,
we'll hack our way to a solution with a manual update of the pg_depend
entry type, which is what distinguishes the two cases. Perhaps
someday it'll be worth providing a cleaner way to do that, but for
now it seems like a very niche problem.
Note that the underlying C functions remain, to support use of the shared
libraries with older versions of the modules' SQL declarations. Someday
we may be able to remove them, but not soon.
Andrey Borodin, reviewed by me
Discussion: https://postgr.es/m/D0F53A05-4F4A-4DEC-8339-3C069FA0EE11@yandex-team.ru
2017-11-21 09:25:18 +08:00
SET enable_bitmapscan = false;
EXPLAIN (COSTS OFF)
SELECT count(*) FROM test_seg WHERE s @> '11..11.3';
QUERY PLAN
-----------------------------------------------------
Aggregate
-> Index Only Scan using test_seg_ix on test_seg
Index Cond: (s @> '1.1e1 .. 11.3'::seg)
(3 rows)
2006-09-11 01:36:52 +08:00
SELECT count(*) FROM test_seg WHERE s @> '11..11.3';
2000-12-12 04:40:33 +08:00
count
-------
143
(1 row)
Support index-only scans in contrib/cube and contrib/seg GiST indexes.
To do this, we only have to remove the compress and decompress support
functions, which have never done anything more than detoasting.
In the wake of commit d3a4f89d8, this results in automatically enabling
index-only scans, since the core code will now know that the stored
representation is the same as the original data (up to detoasting).
The only exciting part of this is that ALTER OPERATOR FAMILY lacks
a way to drop a support function that was declared as being part of
an opclass rather than being loose in the family. For the moment,
we'll hack our way to a solution with a manual update of the pg_depend
entry type, which is what distinguishes the two cases. Perhaps
someday it'll be worth providing a cleaner way to do that, but for
now it seems like a very niche problem.
Note that the underlying C functions remain, to support use of the shared
libraries with older versions of the modules' SQL declarations. Someday
we may be able to remove them, but not soon.
Andrey Borodin, reviewed by me
Discussion: https://postgr.es/m/D0F53A05-4F4A-4DEC-8339-3C069FA0EE11@yandex-team.ru
2017-11-21 09:25:18 +08:00
RESET enable_bitmapscan;
2010-11-24 04:27:50 +08:00
-- Test sorting
2006-09-11 01:36:52 +08:00
SELECT * FROM test_seg WHERE s @> '11..11.3' GROUP BY s;
2000-12-12 04:40:33 +08:00
s
-----------------
.. 4.0e1
.. >8.2e1
.. 9.0e1
<1.0 .. >13.0
1.3 .. 12.0
2.0 .. 11.5
2.1 .. 11.8
<2.3 ..
>2.3 ..
2.4 .. 11.3
2.5 .. 11.5
2.5 .. 11.8
2.6 ..
2.7 .. 12.0
<3.0 ..
3 .. 5.8e1
3.1 .. 11.5
3.5 .. 11.5
3.5 .. 12.2
<4.0 .. >1.2e1
<4.0 ..
4 .. 1.2e1
4.0 .. 11.7
4.0 .. 12.5
4.0 .. 13.0
4.0 .. 6.0e1
4.0 ..
4.2 .. 11.5
4.2 .. 11.7
<4.5 .. >1.2e1
4.5 .. 11.5
4.5 .. <1.2e1
4.5 .. >1.2e1
4.5 .. 12.5
4.5 .. 1.15e2
4.7 .. 11.8
4.8 .. 11.5
4.8 .. 11.6
4.8 .. 12.5
4.8 ..
4.9 .. >1.2e1
4.9 ..
5 .. 11.5
5 .. 1.2e1
5 .. 3.0e1
5.0 .. 11.4
5.0 .. 11.5
5.0 .. 11.6
5.0 .. 11.7
5.0 .. 12.0
5.0 .. >12.0
5.0 .. >1.2e1
5.2 .. 11.5
5.2 .. >1.2e1
5.25 .. >1.2e1
5.3 .. 11.5
5.3 .. 1.3e1
5.3 .. >9.0e1
5.3 ..
5.4 ..
5.5 .. 11.5
5.5 .. 11.7
5.5 .. 1.2e1
5.5 .. >1.2e1
5.5 .. 12.5
5.5 .. 13.5
5.5 ..
>5.5 ..
5.7 ..
5.9 ..
6 .. 11.5
6 .. >1.2e1
6.0 .. 11.5
6.0 .. 1.3e1
>6.0 .. <11.5
6.1 .. >1.2e1
6.1 ..
6.2 .. >11.5
6.3 ..
6.5 .. 11.5
6.5 .. 12.0
6.5 .. >12.0
6.5 ..
6.6 ..
6.7 .. 11.5
6.7 ..
6.75 ..
6.8 ..
6.9 .. 12.2
6.9 .. >9.0e1
6.9 ..
<7.0 .. >11.5
7.0 .. 11.5
7.0 .. >11.5
7.0 ..
>7.15 ..
7.2 .. 13.5
7.3 .. >9.0e1
7.3 ..
>7.3 ..
7.4 .. 12.1
7.4 ..
7.5 .. 11.5
7.5 .. 12.0
7.5 ..
7.7 .. 11.5
7.7 ..
7.75 ..
8.0 .. 11.7
8.0 .. 12.0
8.0 .. >13.0
8.2 ..
8.3 ..
8.5 .. >11.5
8.5 .. 12.5
8.5 ..
8.6 .. >9.9e1
8.7 .. 11.3
8.7 .. 11.7
8.9 .. 11.5
9 .. >1.2e1
9.0 .. 11.3
9.0 .. 11.5
9.0 .. 1.2e1
9.0 ..
9.2 .. 1.2e1
9.4 .. 12.2
<9.5 .. 1.2e1
<9.5 .. >12.2
9.5 ..
9.6 .. 11.5
9.7 .. 11.5
9.7 .. >1.2e1
9.8 .. >12.5
<1.0e1 .. >11.6
10.0 .. 11.5
10.0 .. 12.5
10.0 .. >12.5
10.2 .. 11.8
<10.5 .. 11.5
10.5 .. 11.5
10.5 .. <13.5
10.7 .. 12.3
(143 rows)
2008-04-19 02:43:09 +08:00
-- Test functions
SELECT seg_lower(s), seg_center(s), seg_upper(s)
FROM test_seg WHERE s @> '11.2..11.3' OR s IS NULL ORDER BY s;
seg_lower | seg_center | seg_upper
-----------+------------+-----------
-Infinity | -Infinity | 40
-Infinity | -Infinity | 82
-Infinity | -Infinity | 90
1 | 7 | 13
1.3 | 6.65 | 12
2 | 6.75 | 11.5
2.1 | 6.95 | 11.8
2.3 | Infinity | Infinity
2.3 | Infinity | Infinity
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 23:20:33 +08:00
2.4 | 6.8500004 | 11.3
2008-04-19 02:43:09 +08:00
2.5 | 7 | 11.5
2.5 | 7.15 | 11.8
2.6 | Infinity | Infinity
2.7 | 7.35 | 12
3 | Infinity | Infinity
3 | 30.5 | 58
3.1 | 7.3 | 11.5
3.5 | 7.5 | 11.5
3.5 | 7.85 | 12.2
4 | 8 | 12
4 | Infinity | Infinity
4 | 8 | 12
4 | 7.85 | 11.7
4 | 8.25 | 12.5
4 | 8.5 | 13
4 | 32 | 60
4 | Infinity | Infinity
4.2 | 7.85 | 11.5
4.2 | 7.95 | 11.7
4.5 | 8.25 | 12
4.5 | 8 | 11.5
4.5 | 8.25 | 12
4.5 | 8.25 | 12
4.5 | 8.5 | 12.5
4.5 | 59.75 | 115
4.7 | 8.25 | 11.8
4.8 | 8.15 | 11.5
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 23:20:33 +08:00
4.8 | 8.200001 | 11.6
2008-04-19 02:43:09 +08:00
4.8 | 8.65 | 12.5
4.8 | Infinity | Infinity
4.9 | 8.45 | 12
4.9 | Infinity | Infinity
5 | 8.25 | 11.5
5 | 8.5 | 12
5 | 17.5 | 30
5 | 8.2 | 11.4
5 | 8.25 | 11.5
5 | 8.3 | 11.6
5 | 8.35 | 11.7
5 | 8.5 | 12
5 | 8.5 | 12
5 | 8.5 | 12
5.2 | 8.35 | 11.5
5.2 | 8.6 | 12
5.25 | 8.625 | 12
5.3 | 8.4 | 11.5
5.3 | 9.15 | 13
5.3 | 47.65 | 90
5.3 | Infinity | Infinity
5.4 | Infinity | Infinity
5.5 | 8.5 | 11.5
5.5 | 8.6 | 11.7
5.5 | 8.75 | 12
5.5 | 8.75 | 12
5.5 | 9 | 12.5
5.5 | 9.5 | 13.5
5.5 | Infinity | Infinity
5.5 | Infinity | Infinity
5.7 | Infinity | Infinity
5.9 | Infinity | Infinity
6 | 8.75 | 11.5
6 | 9 | 12
6 | 8.75 | 11.5
6 | 9.5 | 13
6 | 8.75 | 11.5
6.1 | 9.05 | 12
6.1 | Infinity | Infinity
6.2 | 8.85 | 11.5
6.3 | Infinity | Infinity
6.5 | 9 | 11.5
6.5 | 9.25 | 12
6.5 | 9.25 | 12
6.5 | Infinity | Infinity
6.6 | Infinity | Infinity
6.7 | 9.1 | 11.5
6.7 | Infinity | Infinity
6.75 | Infinity | Infinity
6.8 | Infinity | Infinity
6.9 | 9.55 | 12.2
6.9 | 48.45 | 90
6.9 | Infinity | Infinity
7 | 9.25 | 11.5
7 | 9.25 | 11.5
7 | 9.25 | 11.5
7 | Infinity | Infinity
7.15 | Infinity | Infinity
7.2 | 10.35 | 13.5
7.3 | 48.65 | 90
7.3 | Infinity | Infinity
7.3 | Infinity | Infinity
7.4 | 9.75 | 12.1
7.4 | Infinity | Infinity
7.5 | 9.5 | 11.5
7.5 | 9.75 | 12
7.5 | Infinity | Infinity
7.7 | 9.6 | 11.5
7.7 | Infinity | Infinity
7.75 | Infinity | Infinity
8 | 9.85 | 11.7
8 | 10 | 12
8 | 10.5 | 13
8.2 | Infinity | Infinity
8.3 | Infinity | Infinity
8.5 | 10 | 11.5
8.5 | 10.5 | 12.5
8.5 | Infinity | Infinity
8.6 | 53.8 | 99
8.7 | 10 | 11.3
8.7 | 10.2 | 11.7
8.9 | 10.2 | 11.5
9 | 10.5 | 12
9 | 10.15 | 11.3
9 | 10.25 | 11.5
9 | 10.5 | 12
9 | Infinity | Infinity
9.2 | 10.6 | 12
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 23:20:33 +08:00
9.4 | 10.799999 | 12.2
2008-04-19 02:43:09 +08:00
9.5 | 10.75 | 12
9.5 | 10.85 | 12.2
9.5 | Infinity | Infinity
9.6 | 10.55 | 11.5
9.7 | 10.6 | 11.5
9.7 | 10.85 | 12
9.8 | 11.15 | 12.5
10 | 10.8 | 11.6
10 | 10.75 | 11.5
10 | 11.25 | 12.5
10 | 11.25 | 12.5
10.2 | 11 | 11.8
10.5 | 11 | 11.5
10.5 | 11 | 11.5
10.5 | 12 | 13.5
10.7 | 11.5 | 12.3
| |
(144 rows)
2022-12-23 22:17:24 +08:00
-- test non error throwing API
SELECT str as seg,
pg_input_is_valid(str,'seg') as ok,
2023-02-28 07:04:13 +08:00
errinfo.sql_error_code,
errinfo.message,
errinfo.detail,
errinfo.hint
2022-12-23 22:17:24 +08:00
FROM unnest(ARRAY['-1 .. 1'::text,
'100(+-)1',
'',
'ABC',
'1 e7',
2023-02-28 07:04:13 +08:00
'1e700']) str,
LATERAL pg_input_error_info(str, 'seg') as errinfo;
seg | ok | sql_error_code | message | detail | hint
----------+----+----------------+---------------------------------------+------------------------------+------
-1 .. 1 | t | | | |
100(+-)1 | t | | | |
| f | 42601 | bad seg representation | syntax error at end of input |
ABC | f | 42601 | bad seg representation | syntax error at or near "A" |
1 e7 | f | 42601 | bad seg representation | syntax error at or near "e" |
1e700 | f | 22003 | "1e700" is out of range for type real | |
2022-12-23 22:17:24 +08:00
(6 rows)
