mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-21 08:29:39 +08:00
Code Issues Packages Projects Releases Wiki Activity
0b49642b99
postgresql/contrib/cube/sql/cube.sql

339 lines
14 KiB
MySQL
Raw Normal View History

Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
--
-- Test cube datatype
--
Convert contrib modules to use the extension facility. This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane
2011-02-14 09:06:41 +08:00
CREATE EXTENSION cube;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
--
-- testing the input and output functions
--
-- Any number (a one-dimensional point)
SELECT '1'::cube AS cube;
SELECT '-1'::cube AS cube;
SELECT '1.'::cube AS cube;
SELECT '-1.'::cube AS cube;
SELECT '.1'::cube AS cube;
SELECT '-.1'::cube AS cube;
SELECT '1.0'::cube AS cube;
SELECT '-1.0'::cube AS cube;
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
SELECT '1e27'::cube AS cube;
SELECT '-1e27'::cube AS cube;
SELECT '1.0e27'::cube AS cube;
SELECT '-1.0e27'::cube AS cube;
SELECT '1e+27'::cube AS cube;
SELECT '-1e+27'::cube AS cube;
SELECT '1.0e+27'::cube AS cube;
SELECT '-1.0e+27'::cube AS cube;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
SELECT '1e-7'::cube AS cube;
SELECT '-1e-7'::cube AS cube;
SELECT '1.0e-7'::cube AS cube;
SELECT '-1.0e-7'::cube AS cube;
SELECT '1e-700'::cube AS cube;
SELECT '-1e-700'::cube AS cube;
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
SELECT '1234567890123456'::cube AS cube;
SELECT '+1234567890123456'::cube AS cube;
SELECT '-1234567890123456'::cube AS cube;
SELECT '.1234567890123456'::cube AS cube;
SELECT '+.1234567890123456'::cube AS cube;
SELECT '-.1234567890123456'::cube AS cube;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
-- simple lists (points)
SELECT '1,2'::cube AS cube;
SELECT '(1,2)'::cube AS cube;
SELECT '1,2,3,4,5'::cube AS cube;
SELECT '(1,2,3,4,5)'::cube AS cube;
-- double lists (cubes)
SELECT '(0),(0)'::cube AS cube;
SELECT '(0),(1)'::cube AS cube;
SELECT '[(0),(0)]'::cube AS cube;
SELECT '[(0),(1)]'::cube AS cube;
SELECT '(0,0,0,0),(0,0,0,0)'::cube AS cube;
SELECT '(0,0,0,0),(1,0,0,0)'::cube AS cube;
SELECT '[(0,0,0,0),(0,0,0,0)]'::cube AS cube;
SELECT '[(0,0,0,0),(1,0,0,0)]'::cube AS cube;
-- invalid input: parse errors
SELECT ''::cube AS cube;
SELECT 'ABC'::cube AS cube;
SELECT '()'::cube AS cube;
SELECT '[]'::cube AS cube;
SELECT '[()]'::cube AS cube;
SELECT '[(1)]'::cube AS cube;
SELECT '[(1),]'::cube AS cube;
SELECT '[(1),2]'::cube AS cube;
SELECT '[(1),(2),(3)]'::cube AS cube;
SELECT '1,'::cube AS cube;
SELECT '1,2,'::cube AS cube;
SELECT '1,,2'::cube AS cube;
SELECT '(1,)'::cube AS cube;
SELECT '(1,2,)'::cube AS cube;
SELECT '(1,,2)'::cube AS cube;
-- invalid input: semantic errors and trailing garbage
SELECT '[(1),(2)],'::cube AS cube; -- 0
SELECT '[(1,2,3),(2,3)]'::cube AS cube; -- 1
SELECT '[(1,2),(1,2,3)]'::cube AS cube; -- 1
SELECT '(1),(2),'::cube AS cube; -- 2
SELECT '(1,2,3),(2,3)'::cube AS cube; -- 3
SELECT '(1,2),(1,2,3)'::cube AS cube; -- 3
SELECT '(1,2,3)ab'::cube AS cube; -- 4
SELECT '(1,2,3)a'::cube AS cube; -- 5
SELECT '(1,2)('::cube AS cube; -- 5
SELECT '1,2ab'::cube AS cube; -- 6
SELECT '1 e7'::cube AS cube; -- 6
SELECT '1,2a'::cube AS cube; -- 7
SELECT '1..2'::cube AS cube; -- 7
The attached patch provides cube with 4 functions for building cubes directly from float8 values. (As opposed to converting the values to strings and then parsing the strings.) The functions are: cube(float8) returns cube cube(float8,float8) returns cube cube(cube,float8) returns cube cube(cube,float8,float8) returns cube Bruno Wolff III
2003-02-13 13:26:50 +08:00
--
-- Testing building cubes from float8 values
--
SELECT cube(0::float8);
SELECT cube(1::float8);
SELECT cube(1,2);
SELECT cube(cube(1,2),3);
SELECT cube(cube(1,2),3,4);
SELECT cube(cube(cube(1,2),3,4),5);
SELECT cube(cube(cube(1,2),3,4),5,6);
--
-- Test that the text -> cube cast was installed.
--
SELECT '(0)'::text::cube;
/contrib/cube improvements: Update the calling convention for all external facing functions. By external facing, I mean all functions that are directly referenced in cube.sql. Prior to my update, all functions used the older V0 calling convention. They now use V1. New Functions: cube(float[]), which makes a zero volume cube from a float array cube(float[], float[]), which allows the user to create a cube from two float arrays; one for the upper right and one for the lower left coordinate. cube_subset(cube, int4[]), to allow you to reorder or choose a subset of dimensions from a cube, using index values specified in the array. Joshua Reich
2006-07-26 07:23:45 +08:00
--
-- Test the float[] -> cube cast
--
SELECT cube('{0,1,2}'::float[], '{3,4,5}'::float[]);
SELECT cube('{0,1,2}'::float[], '{3}'::float[]);
SELECT cube(NULL::float[], '{3}'::float[]);
SELECT cube('{0,1,2}'::float[]);
Remove useless whitespace at end of lines
2010-11-24 04:27:50 +08:00
SELECT cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[3,2,1,1]);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_subset(cube('(1,3,5),(1,3,5)'), ARRAY[3,2,1,1]);
Remove useless whitespace at end of lines
2010-11-24 04:27:50 +08:00
SELECT cube_subset(cube('(1,3,5),(6,7,8)'), ARRAY[4,0]);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_subset(cube('(6,7,8),(6,7,8)'), ARRAY[4,0]);
--
-- Test point processing
--
SELECT cube('(1,2),(1,2)'); -- cube_in
SELECT cube('{0,1,2}'::float[], '{0,1,2}'::float[]); -- cube_a_f8_f8
SELECT cube('{5,6,7,8}'::float[]); -- cube_a_f8
SELECT cube(1.37); -- cube_f8
SELECT cube(1.37, 1.37); -- cube_f8_f8
SELECT cube(cube(1,1), 42); -- cube_c_f8
SELECT cube(cube(1,2), 42); -- cube_c_f8
SELECT cube(cube(1,1), 42, 42); -- cube_c_f8_f8
SELECT cube(cube(1,1), 42, 24); -- cube_c_f8_f8
SELECT cube(cube(1,2), 42, 42); -- cube_c_f8_f8
SELECT cube(cube(1,2), 42, 24); -- cube_c_f8_f8
/contrib/cube improvements: Update the calling convention for all external facing functions. By external facing, I mean all functions that are directly referenced in cube.sql. Prior to my update, all functions used the older V0 calling convention. They now use V1. New Functions: cube(float[]), which makes a zero volume cube from a float array cube(float[], float[]), which allows the user to create a cube from two float arrays; one for the upper right and one for the lower left coordinate. cube_subset(cube, int4[]), to allow you to reorder or choose a subset of dimensions from a cube, using index values specified in the array. Joshua Reich
2006-07-26 07:23:45 +08:00
This is a comprehensive set of diffs (versus current CVS) that replaces those attached to the same message with the Earth Distance patches. Recent changes include changing the subscript in one place I forgot in the previous bugfix patch. A couple of added regression tests, which should help catch this mistake if it reappears. I also put in a limit of 100 dimensions in cube_large and cube_in to prevent making it easy to create very large cubes. Changing one define in cubedata.h will raise the limit if some needs more dimensions. Bruno Wolff III
2002-09-12 08:26:00 +08:00
--
-- Testing limit of CUBE_MAX_DIM dimensions check in cube_in.
--
select '(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)'::cube;
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;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
--
-- testing the operators
--
-- equality/inequality:
--
SELECT '24, 33.20'::cube = '24, 33.20'::cube AS bool;
SELECT '24, 33.20'::cube != '24, 33.20'::cube AS bool;
SELECT '24, 33.20'::cube = '24, 33.21'::cube AS bool;
SELECT '24, 33.20'::cube != '24, 33.21'::cube AS bool;
SELECT '(2,0),(3,1)'::cube = '(2,0,0,0,0),(3,1,0,0,0)'::cube AS bool;
SELECT '(2,0),(3,1)'::cube = '(2,0,0,0,0),(3,1,0,0,1)'::cube AS bool;
-- "lower than" / "greater than"
-- (these operators are not useful for anything but ordering)
--
SELECT '1'::cube > '2'::cube AS bool;
SELECT '1'::cube < '2'::cube AS bool;
SELECT '1,1'::cube > '1,2'::cube AS bool;
SELECT '1,1'::cube < '1,2'::cube AS bool;
SELECT '(2,0),(3,1)'::cube > '(2,0,0,0,0),(3,1,0,0,1)'::cube AS bool;
SELECT '(2,0),(3,1)'::cube < '(2,0,0,0,0),(3,1,0,0,1)'::cube AS bool;
SELECT '(2,0),(3,1)'::cube > '(2,0,0,0,1),(3,1,0,0,0)'::cube AS bool;
SELECT '(2,0),(3,1)'::cube < '(2,0,0,0,1),(3,1,0,0,0)'::cube AS bool;
SELECT '(2,0),(3,1)'::cube > '(2,0,0,0,0),(3,1,0,0,0)'::cube AS bool;
SELECT '(2,0),(3,1)'::cube < '(2,0,0,0,0),(3,1,0,0,0)'::cube AS bool;
SELECT '(2,0,0,0,0),(3,1,0,0,1)'::cube > '(2,0),(3,1)'::cube AS bool;
SELECT '(2,0,0,0,0),(3,1,0,0,1)'::cube < '(2,0),(3,1)'::cube AS bool;
SELECT '(2,0,0,0,1),(3,1,0,0,0)'::cube > '(2,0),(3,1)'::cube AS bool;
SELECT '(2,0,0,0,1),(3,1,0,0,0)'::cube < '(2,0),(3,1)'::cube AS bool;
SELECT '(2,0,0,0,0),(3,1,0,0,0)'::cube > '(2,0),(3,1)'::cube AS bool;
SELECT '(2,0,0,0,0),(3,1,0,0,0)'::cube < '(2,0),(3,1)'::cube AS bool;
-- "overlap"
--
SELECT '1'::cube && '1'::cube AS bool;
SELECT '1'::cube && '2'::cube AS bool;
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '0'::cube AS bool;
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '1'::cube AS bool;
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '1,1,1'::cube AS bool;
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '[(1,1,1),(2,2,2)]'::cube AS bool;
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '[(1,1),(2,2)]'::cube AS bool;
SELECT '[(-1,-1,-1),(1,1,1)]'::cube && '[(2,1,1),(2,2,2)]'::cube AS bool;
-- "contained in" (the left operand is the cube entirely enclosed by
-- the right operand):
--
Rename contrib contains/contained-by operators to @> and <@, per discussion.
2006-09-11 01:36:52 +08:00
SELECT '0'::cube <@ '0'::cube AS bool;
SELECT '0,0,0'::cube <@ '0,0,0'::cube AS bool;
SELECT '0,0'::cube <@ '0,0,1'::cube AS bool;
SELECT '0,0,0'::cube <@ '0,0,1'::cube AS bool;
SELECT '1,0,0'::cube <@ '0,0,1'::cube AS bool;
SELECT '(1,0,0),(0,0,1)'::cube <@ '(1,0,0),(0,0,1)'::cube AS bool;
SELECT '(1,0,0),(0,0,1)'::cube <@ '(-1,-1,-1),(1,1,1)'::cube AS bool;
SELECT '(1,0,0),(0,0,1)'::cube <@ '(-1,-1,-1,-1),(1,1,1,1)'::cube AS bool;
SELECT '0'::cube <@ '(-1),(1)'::cube AS bool;
SELECT '1'::cube <@ '(-1),(1)'::cube AS bool;
SELECT '-1'::cube <@ '(-1),(1)'::cube AS bool;
SELECT '(-1),(1)'::cube <@ '(-1),(1)'::cube AS bool;
SELECT '(-1),(1)'::cube <@ '(-1,-1),(1,1)'::cube AS bool;
SELECT '(-2),(1)'::cube <@ '(-1),(1)'::cube AS bool;
SELECT '(-2),(1)'::cube <@ '(-1,-1),(1,1)'::cube AS bool;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
-- "contains" (the left operand is the cube that entirely encloses the
-- right operand)
--
Rename contrib contains/contained-by operators to @> and <@, per discussion.
2006-09-11 01:36:52 +08:00
SELECT '0'::cube @> '0'::cube AS bool;
SELECT '0,0,0'::cube @> '0,0,0'::cube AS bool;
SELECT '0,0,1'::cube @> '0,0'::cube AS bool;
SELECT '0,0,1'::cube @> '0,0,0'::cube AS bool;
SELECT '0,0,1'::cube @> '1,0,0'::cube AS bool;
SELECT '(1,0,0),(0,0,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
SELECT '(-1,-1,-1),(1,1,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
SELECT '(-1,-1,-1,-1),(1,1,1,1)'::cube @> '(1,0,0),(0,0,1)'::cube AS bool;
SELECT '(-1),(1)'::cube @> '0'::cube AS bool;
SELECT '(-1),(1)'::cube @> '1'::cube AS bool;
SELECT '(-1),(1)'::cube @> '-1'::cube AS bool;
SELECT '(-1),(1)'::cube @> '(-1),(1)'::cube AS bool;
SELECT '(-1,-1),(1,1)'::cube @> '(-1),(1)'::cube AS bool;
SELECT '(-1),(1)'::cube @> '(-2),(1)'::cube AS bool;
SELECT '(-1,-1),(1,1)'::cube @> '(-2),(1)'::cube AS bool;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
-- Test of distance function
--
SELECT cube_distance('(0)'::cube,'(2,2,2,2)'::cube);
SELECT cube_distance('(0)'::cube,'(.3,.4)'::cube);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_distance('(2,3,4)'::cube,'(2,3,4)'::cube);
SELECT cube_distance('(42,42,42,42)'::cube,'(137,137,137,137)'::cube);
SELECT cube_distance('(42,42,42)'::cube,'(137,137)'::cube);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
-- Test of cube function (text to cube)
--
Downgrade implicit casts to text to be assignment-only, except for the ones from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
2007-06-06 05:31:09 +08:00
SELECT cube('(1,1.2)'::text);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
SELECT cube(NULL);
-- Test of cube_dim function (dimensions stored in cube)
--
SELECT cube_dim('(0)'::cube);
SELECT cube_dim('(0,0)'::cube);
SELECT cube_dim('(0,0,0)'::cube);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_dim('(42,42,42),(42,42,42)'::cube);
SELECT cube_dim('(4,8,15,16,23),(4,8,15,16,23)'::cube);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
-- Test of cube_ll_coord function (retrieves LL coodinate values)
--
SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 1);
SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 2);
SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 3);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_ll_coord('(1,2),(1,2)'::cube, 1);
SELECT cube_ll_coord('(1,2),(1,2)'::cube, 2);
SELECT cube_ll_coord('(1,2),(1,2)'::cube, 3);
SELECT cube_ll_coord('(42,137)'::cube, 1);
SELECT cube_ll_coord('(42,137)'::cube, 2);
SELECT cube_ll_coord('(42,137)'::cube, 3);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
-- Test of cube_ur_coord function (retrieves UR coodinate values)
--
SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 1);
SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 2);
SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 3);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_ur_coord('(1,2),(1,2)'::cube, 1);
SELECT cube_ur_coord('(1,2),(1,2)'::cube, 2);
SELECT cube_ur_coord('(1,2),(1,2)'::cube, 3);
SELECT cube_ur_coord('(42,137)'::cube, 1);
SELECT cube_ur_coord('(42,137)'::cube, 2);
SELECT cube_ur_coord('(42,137)'::cube, 3);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
-- Test of cube_is_point
--
SELECT cube_is_point('(0)'::cube);
SELECT cube_is_point('(0,1,2)'::cube);
SELECT cube_is_point('(0,1,2),(0,1,2)'::cube);
SELECT cube_is_point('(0,1,2),(-1,1,2)'::cube);
SELECT cube_is_point('(0,1,2),(0,-1,2)'::cube);
SELECT cube_is_point('(0,1,2),(0,1,-2)'::cube);
-- Test of cube_enlarge (enlarging and shrinking cubes)
--
SELECT cube_enlarge('(0)'::cube, 0, 0);
SELECT cube_enlarge('(0)'::cube, 0, 1);
SELECT cube_enlarge('(0)'::cube, 0, 2);
This is a comprehensive set of diffs (versus current CVS) that replaces those attached to the same message with the Earth Distance patches. Recent changes include changing the subscript in one place I forgot in the previous bugfix patch. A couple of added regression tests, which should help catch this mistake if it reappears. I also put in a limit of 100 dimensions in cube_large and cube_in to prevent making it easy to create very large cubes. Changing one define in cubedata.h will raise the limit if some needs more dimensions. Bruno Wolff III
2002-09-12 08:26:00 +08:00
SELECT cube_enlarge('(2),(-2)'::cube, 0, 4);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
SELECT cube_enlarge('(0)'::cube, 1, 0);
SELECT cube_enlarge('(0)'::cube, 1, 1);
SELECT cube_enlarge('(0)'::cube, 1, 2);
This is a comprehensive set of diffs (versus current CVS) that replaces those attached to the same message with the Earth Distance patches. Recent changes include changing the subscript in one place I forgot in the previous bugfix patch. A couple of added regression tests, which should help catch this mistake if it reappears. I also put in a limit of 100 dimensions in cube_large and cube_in to prevent making it easy to create very large cubes. Changing one define in cubedata.h will raise the limit if some needs more dimensions. Bruno Wolff III
2002-09-12 08:26:00 +08:00
SELECT cube_enlarge('(2),(-2)'::cube, 1, 4);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
SELECT cube_enlarge('(0)'::cube, -1, 0);
SELECT cube_enlarge('(0)'::cube, -1, 1);
SELECT cube_enlarge('(0)'::cube, -1, 2);
This is a comprehensive set of diffs (versus current CVS) that replaces those attached to the same message with the Earth Distance patches. Recent changes include changing the subscript in one place I forgot in the previous bugfix patch. A couple of added regression tests, which should help catch this mistake if it reappears. I also put in a limit of 100 dimensions in cube_large and cube_in to prevent making it easy to create very large cubes. Changing one define in cubedata.h will raise the limit if some needs more dimensions. Bruno Wolff III
2002-09-12 08:26:00 +08:00
SELECT cube_enlarge('(2),(-2)'::cube, -1, 4);
The changes I have made are described in CHANGES. This was based on diffs to 7.3-devel and may not be applicable to 7.2. I have included a change covered by a previous bugfix patch I submitted (the problem with -.1 not being accepted by cube_in). It does not include a fix for the potential buffer overrun issue I reported for cube_yyerror in cubeparse.y. Bruno Wolff III
2002-08-30 07:03:58 +08:00
SELECT cube_enlarge('(0,0,0)'::cube, 1, 0);
SELECT cube_enlarge('(0,0,0)'::cube, 1, 2);
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, 1, 2);
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, 3, 2);
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, -1, 2);
SELECT cube_enlarge('(2,-2),(-3,7)'::cube, -3, 2);
Extend cube on-disk format to pack points more tightly. If the lower left and upper right corners of a cube are the same, set a flag in the cube header, and only store one copy of the coordinates. That cuts the on-disk size into half for the common case that the cube datatype is used to represent points rather than boxes. The new format is backwards-compatible with the old one, so pg_upgrade still works. However, to get the space savings, the data needs to be rewritten. A simple VACUUM FULL or REINDEX is not enough, as the old Datums will just be moved to the new heap/index as is. A pg_dump and reload, or something similar like casting to text and back, will do the trick. This patch deliberately doesn't update all the alternative expected output files, as I don't have access to machines that produce those outputs. I'm not sure if they are still relevant, but if they are, the buildfarm will tell us and produce the diff required to fix it. If none of the buildfarm animals need them, they should be removed altogether. Patch by Stas Kelvich.
2013-10-22 01:59:42 +08:00
SELECT cube_enlarge('(42,-23,-23),(42,23,23)'::cube, -23, 5);
SELECT cube_enlarge('(42,-23,-23),(42,23,23)'::cube, -24, 5);
-- Test of cube_union (MBR for two cubes)
--
SELECT cube_union('(1,2),(3,4)'::cube, '(5,6,7),(8,9,10)'::cube);
SELECT cube_union('(1,2)'::cube, '(4,2,0,0)'::cube);
SELECT cube_union('(1,2),(1,2)'::cube, '(4,2),(4,2)'::cube);
SELECT cube_union('(1,2),(1,2)'::cube, '(1,2),(1,2)'::cube);
SELECT cube_union('(1,2),(1,2)'::cube, '(1,2,0),(1,2,0)'::cube);
-- Test of cube_inter
--
SELECT cube_inter('(1,2),(10,11)'::cube, '(3,4), (16,15)'::cube); -- intersects
SELECT cube_inter('(1,2),(10,11)'::cube, '(3,4), (6,5)'::cube); -- includes
SELECT cube_inter('(1,2),(10,11)'::cube, '(13,14), (16,15)'::cube); -- no intersection
SELECT cube_inter('(1,2),(10,11)'::cube, '(3,14), (16,15)'::cube); -- no intersection, but one dimension intersects
SELECT cube_inter('(1,2),(10,11)'::cube, '(10,11), (16,15)'::cube); -- point intersection
SELECT cube_inter('(1,2,3)'::cube, '(1,2,3)'::cube); -- point args
SELECT cube_inter('(1,2,3)'::cube, '(5,6,3)'::cube); -- point args
-- Test of cube_size
--
SELECT cube_size('(4,8),(15,16)'::cube);
SELECT cube_size('(42,137)'::cube);
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
-- Load some example data and build the index
Remove useless whitespace at end of lines
2010-11-24 04:27:50 +08:00
--
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
CREATE TABLE test_cube (c cube);
\copy test_cube from 'data/test_cube.data'
CREATE INDEX test_cube_ix ON test_cube USING gist (c);
Remove useless whitespace at end of lines
2010-11-24 04:27:50 +08:00
SELECT * FROM test_cube WHERE c && '(3000,1000),(0,0)' ORDER BY c;
Gene Selkov's CUBE datatype (GiST example code)
2000-12-12 04:39:15 +08:00
Remove useless whitespace at end of lines
2010-11-24 04:27:50 +08:00
-- Test sorting
SELECT * FROM test_cube WHERE c && '(3000,1000),(0,0)' GROUP BY c ORDER BY c;
Reference in New Issue Copy Permalink