delta/postgresql.git/src/test/regress/expected/polygon.out, branch master git.postgresql.org: git/postgresql.git Rework pg_input_error_message(), now renamed pg_input_error_info() 2023-02-27T23:04:13+00:00 Michael Paquier michael@paquier.xyz 2023-02-27T23:04:13+00:00 b8da37b3ada2e547983538b3e49f8079f85ce120 pg_input_error_info() is now a SQL function able to return a row with more than just the error message generated for incorrect data type inputs when these are able to handle soft failures, returning more contents of ErrorData, as of: - The error message (same as before). - The error detail, if set. - The error hint, if set. - SQL error code. All the regression tests that relied on pg_input_error_message() are updated to reflect the effects of the rename. Per discussion with Tom Lane and Andrew Dunstan. Author: Nathan Bossart Discussion: https://postgr.es/m/139a68e1-bd1f-a9a7-b5fe-0be9845c6311@dunslane.net 
pg_input_error_info() is now a SQL function able to return a row with
more than just the error message generated for incorrect data type
inputs when these are able to handle soft failures, returning more
contents of ErrorData, as of:
- The error message (same as before).
- The error detail, if set.
- The error hint, if set.
- SQL error code.

All the regression tests that relied on pg_input_error_message() are
updated to reflect the effects of the rename.

Per discussion with Tom Lane and Andrew Dunstan.

Author: Nathan Bossart
Discussion: https://postgr.es/m/139a68e1-bd1f-a9a7-b5fe-0be9845c6311@dunslane.net
Convert the geometric input functions to report errors softly. 2022-12-14T21:10:20+00:00 Tom Lane tgl@sss.pgh.pa.us 2022-12-14T21:10:20+00:00 332741e73980401895e027eb697bb472860036fb Convert box_in, circle_in, line_in, lseg_in, path_in, point_in, and poly_in to the new style. line_in still throws hard errors for overflows/underflows that can occur when the input is specified as two points rather than in the canonical "Ax + By + C = 0" style. I'm not too concerned about that: it won't be reached in normal dump/restore cases, and it's fairly debatable that such conversion should ever have been made part of a type input function in the first place. But in any case, I don't want to extend the soft error conventions into float.h without more discussion than this patch has had. Amul Sul, minor mods by me Discussion: https://postgr.es/m/CAAJ_b97KeDWUdpTKGOaFYPv0OicjOu6EW+QYWj-Ywrgj_aEy1g@mail.gmail.com 
Convert box_in, circle_in, line_in, lseg_in, path_in, point_in,
and poly_in to the new style.

line_in still throws hard errors for overflows/underflows that can occur
when the input is specified as two points rather than in the canonical
"Ax + By + C = 0" style.  I'm not too concerned about that: it won't be
reached in normal dump/restore cases, and it's fairly debatable that
such conversion should ever have been made part of a type input function
in the first place.  But in any case, I don't want to extend the soft
error conventions into float.h without more discussion than this patch
has had.

Amul Sul, minor mods by me

Discussion: https://postgr.es/m/CAAJ_b97KeDWUdpTKGOaFYPv0OicjOu6EW+QYWj-Ywrgj_aEy1g@mail.gmail.com
Clean up ancient test style 2020-12-15T21:03:39+00:00 Peter Eisentraut peter@eisentraut.org 2020-12-15T20:54:06+00:00 c06d6aa4c35177655e0fd4acaca888a73c3f9845 Many older tests where written in a style like SELECT '' AS two, i.* FROM INT2_TBL where the first column indicated the number of expected result rows. This has gotten increasingly out of date, as the test data fixtures have expanded, so a lot of these were wrong and misleading. Moreover, this style isn't really necessary, since the psql output already shows the number of result rows. To clean this up, remove all those extra columns. Discussion: https://www.postgresql.org/message-id/flat/1a25312b-2686-380d-3c67-7a69094a999f%40enterprisedb.com 
Many older tests where written in a style like

    SELECT '' AS two, i.* FROM INT2_TBL

where the first column indicated the number of expected result rows.
This has gotten increasingly out of date, as the test data fixtures
have expanded, so a lot of these were wrong and misleading.  Moreover,
this style isn't really necessary, since the psql output already shows
the number of result rows.

To clean this up, remove all those extra columns.

Discussion: https://www.postgresql.org/message-id/flat/1a25312b-2686-380d-3c67-7a69094a999f%40enterprisedb.com
Fix double-word typos 2019-06-13T14:03:56+00:00 Alvaro Herrera alvherre@alvh.no-ip.org 2019-06-12T18:16:18+00:00 b9768458154de6c001af23efc02514f120c6094f Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql Reviewed-by: Michaël Paquier 
Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql
Reviewed-by: Michaël Paquier
Remove duplicative polygon SP-GiST sequencing test. 2019-04-11T18:35:47+00:00 Tom Lane tgl@sss.pgh.pa.us 2019-04-11T18:35:47+00:00 4aaa3b5cf1c33d713b8eefa3612a9112cbcf1074 Code coverage comparisons confirm that the tests using quad_poly_tbl_ord_seq1/quad_poly_tbl_ord_idx1 hit no code paths not also covered by the similar tests using quad_poly_tbl_ord_seq2/quad_poly_tbl_ord_idx2. Since these test cases are pretty expensive, they need to contribute more than zero benefit. In passing, make quad_poly_tbl_ord_seq2 a temp table, since there seems little reason to keep it around after the test. Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us 
Code coverage comparisons confirm that the tests using
quad_poly_tbl_ord_seq1/quad_poly_tbl_ord_idx1 hit no code
paths not also covered by the similar tests using
quad_poly_tbl_ord_seq2/quad_poly_tbl_ord_idx2.  Since these
test cases are pretty expensive, they need to contribute more
than zero benefit.

In passing, make quad_poly_tbl_ord_seq2 a temp table, since
there seems little reason to keep it around after the test.

Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us
Improve test coverage of geometric types 2018-09-26T08:45:21+00:00 Tomas Vondra tomas.vondra@postgresql.org 2018-09-26T08:45:21+00:00 a3d2844852dc664718320b15cbc6d6bfa264e66e This commit significantly increases test coverage of geo_ops.c, adding tests for various issues addressed by 2e2a392de3 (which went undetected for a long time, at least partially due to not being covered). This also removes alternative results expecting -0 on some platforms. Instead the functions are should return the same results everywhere, transforming -0 to 0 if needed. The tests are added to geometric.sql file, sorted by the left hand side of the operators. There are many cross datatype operators, so this seems like the best solution. Author: Emre Hasegeli Reviewed-by: Tomas Vondra Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com 
This commit significantly increases test coverage of geo_ops.c, adding
tests for various issues addressed by 2e2a392de3 (which went undetected
for a long time, at least partially due to not being covered).

This also removes alternative results expecting -0 on some platforms.
Instead the functions are should return the same results everywhere,
transforming -0 to 0 if needed.

The tests are added to geometric.sql file, sorted by the left hand side
of the operators. There are many cross datatype operators, so this seems
like the best solution.

Author: Emre Hasegeli
Reviewed-by: Tomas Vondra

Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
Add support for nearest-neighbor (KNN) searches to SP-GiST 2018-09-18T22:54:10+00:00 Alexander Korotkov akorotkov@postgresql.org 2018-09-18T22:54:10+00:00 2a6368343ff43743ddd90d0f4c2d0ac03e18aa85 Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov 
Currently, KNN searches were supported only by GiST.  SP-GiST also capable to
support them.  This commit implements that support.  SP-GiST scan stack is
replaced with queue, which serves as stack if no ordering is specified.  KNN
support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops
and poly_ops (catversion is bumped).  Some common parts between GiST and SP-GiST
KNNs are extracted into separate functions.

Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru
Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov
Review: Andrey Borodin, Alexander Korotkov
Add polygon opclass for SP-GiST 2017-12-25T15:59:38+00:00 Teodor Sigaev teodor@sigaev.ru 2017-12-25T15:59:38+00:00 ff963b393ca93a71d2f398c4c584b322cd351c2c Polygon opclass uses compress method feature of SP-GiST added earlier. For now it's a single operator class which uses this feature. SP-GiST actually indexes a bounding boxes of input polygons, so part of supported operations are lossy. Opclass uses most methods of corresponding opclass over boxes of SP-GiST and treats bounding boxes as point in 4D-space. Bump catalog version. Authors: Nikita Glukhov, Alexander Korotkov with minor editorization by me Reviewed-By: all authors + Darafei Praliaskouski Discussion: https://www.postgresql.org/message-id/flat/54907069.1030506@sigaev.ru 
Polygon opclass uses compress method feature of SP-GiST added earlier. For now
it's a single operator class which uses this feature. SP-GiST actually indexes
a bounding boxes of input polygons, so part of supported operations are lossy.
Opclass uses most methods of corresponding opclass over boxes of SP-GiST and
treats bounding boxes as point in 4D-space.

Bump catalog version.

Authors: Nikita Glukhov, Alexander Korotkov with minor editorization by me
Reviewed-By: all authors + Darafei Praliaskouski
Discussion: https://www.postgresql.org/message-id/flat/54907069.1030506@sigaev.ru
regression tests: remove polygon diagrams 2015-03-20T02:10:52+00:00 Bruce Momjian bruce@momjian.us 2015-03-20T02:10:52+00:00 05d1910c1c1f4195065882aa077114bc590b45e3 The diagrams were inaccurate. Report by Emre Hasegeli 
The diagrams were inaccurate.

Report by Emre Hasegeli
Add point <-> polygon distance operator. 2014-12-15T15:06:21+00:00 Heikki Linnakangas heikki.linnakangas@iki.fi 2014-12-15T15:02:49+00:00 4520ba67691fc13bb8be2cc47dd0bf8c7ab94205 Alexander Korotkov, reviewed by Emre Hasegeli. 
Alexander Korotkov, reviewed by Emre Hasegeli.