<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/postgresql.git/src/test/regress/expected/int8.out, branch master</title>
<subtitle>git.postgresql.org: git/postgresql.git
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/'/>
<entry>
<title>Rework pg_input_error_message(), now renamed pg_input_error_info()</title>
<updated>2023-02-27T23:04:13+00:00</updated>
<author>
<name>Michael Paquier</name>
<email>michael@paquier.xyz</email>
</author>
<published>2023-02-27T23:04:13+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=b8da37b3ada2e547983538b3e49f8079f85ce120'/>
<id>b8da37b3ada2e547983538b3e49f8079f85ce120</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Allow underscores in integer and numeric constants.</title>
<updated>2023-02-04T09:48:51+00:00</updated>
<author>
<name>Dean Rasheed</name>
<email>dean.a.rasheed@gmail.com</email>
</author>
<published>2023-02-04T09:48:51+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=faff8f8e47f18c7d589453e2e0d841d2bd96c1ac'/>
<id>faff8f8e47f18c7d589453e2e0d841d2bd96c1ac</id>
<content type='text'>
This allows underscores to be used in integer and numeric literals,
and their corresponding type input functions, for visual grouping.
For example:

    1_500_000_000
    3.14159_26535_89793
    0xffff_ffff
    0b_1001_0001

A single underscore is allowed between any 2 digits, or immediately
after the base prefix indicator of non-decimal integers, per SQL:202x
draft.

Peter Eisentraut and Dean Rasheed

Discussion: https://postgr.es/m/84aae844-dc55-a4be-86d9-4f0fa405cc97%40enterprisedb.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows underscores to be used in integer and numeric literals,
and their corresponding type input functions, for visual grouping.
For example:

    1_500_000_000
    3.14159_26535_89793
    0xffff_ffff
    0b_1001_0001

A single underscore is allowed between any 2 digits, or immediately
after the base prefix indicator of non-decimal integers, per SQL:202x
draft.

Peter Eisentraut and Dean Rasheed

Discussion: https://postgr.es/m/84aae844-dc55-a4be-86d9-4f0fa405cc97%40enterprisedb.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Non-decimal integer literals</title>
<updated>2022-12-14T05:17:07+00:00</updated>
<author>
<name>Peter Eisentraut</name>
<email>peter@eisentraut.org</email>
</author>
<published>2022-12-14T04:40:38+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=6fcda9aba83449082124825b6d375c0a61e21c42'/>
<id>6fcda9aba83449082124825b6d375c0a61e21c42</id>
<content type='text'>
Add support for hexadecimal, octal, and binary integer literals:

    0x42F
    0o273
    0b100101

per SQL:202x draft.

This adds support in the lexer as well as in the integer type input
functions.

Reviewed-by: John Naylor &lt;john.naylor@enterprisedb.com&gt;
Reviewed-by: Zhihong Yu &lt;zyu@yugabyte.com&gt;
Reviewed-by: David Rowley &lt;dgrowleyml@gmail.com&gt;
Reviewed-by: Dean Rasheed &lt;dean.a.rasheed@gmail.com&gt;
Discussion: https://www.postgresql.org/message-id/flat/b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for hexadecimal, octal, and binary integer literals:

    0x42F
    0o273
    0b100101

per SQL:202x draft.

This adds support in the lexer as well as in the integer type input
functions.

Reviewed-by: John Naylor &lt;john.naylor@enterprisedb.com&gt;
Reviewed-by: Zhihong Yu &lt;zyu@yugabyte.com&gt;
Reviewed-by: David Rowley &lt;dgrowleyml@gmail.com&gt;
Reviewed-by: Dean Rasheed &lt;dean.a.rasheed@gmail.com&gt;
Discussion: https://www.postgresql.org/message-id/flat/b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Convert a few datatype input functions to use "soft" error reporting.</title>
<updated>2022-12-09T15:14:53+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2022-12-09T15:14:53+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=ccff2d20ed9622815df2a7deffce8a7b14830965'/>
<id>ccff2d20ed9622815df2a7deffce8a7b14830965</id>
<content type='text'>
This patch converts the input functions for bool, int2, int4, int8,
float4, float8, numeric, and contrib/cube to the new soft-error style.
array_in and record_in are also converted.  There's lots more to do,
but this is enough to provide proof-of-concept that the soft-error
API is usable, as well as reference examples for how to convert
input functions.

This patch is mostly by me, but it owes very substantial debt to
earlier work by Nikita Glukhov, Andrew Dunstan, and Amul Sul.
Thanks to Andres Freund for review.

Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch converts the input functions for bool, int2, int4, int8,
float4, float8, numeric, and contrib/cube to the new soft-error style.
array_in and record_in are also converted.  There's lots more to do,
but this is enough to provide proof-of-concept that the soft-error
API is usable, as well as reference examples for how to convert
input functions.

This patch is mostly by me, but it owes very substantial debt to
earlier work by Nikita Glukhov, Andrew Dunstan, and Amul Sul.
Thanks to Andres Freund for review.

Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru
</pre>
</div>
</content>
</entry>
<entry>
<title>Rearrange core regression tests to reduce cross-script dependencies.</title>
<updated>2022-02-08T20:30:38+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2022-02-08T20:30:38+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=cc50080a828dd4791b43539f5a0f976e535d147c'/>
<id>cc50080a828dd4791b43539f5a0f976e535d147c</id>
<content type='text'>
The idea behind this patch is to make it possible to run individual
test scripts without running the entire core test suite.  Making all
the scripts completely independent would involve a massive rewrite,
and would probably be worse for coverage of things like concurrent DDL.
So this patch just does what seems practical with limited changes.

The net effect is that any test script can be run after running
limited earlier dependencies:
* all scripts depend on test_setup
* many scripts depend on create_index
* other dependencies are few in number, and are documented in
  the parallel_schedule file.

To accomplish this, I chose a small number of commonly-used tables
and moved their creation and filling into test_setup.  Later scripts
are expected not to modify these tables' data contents, for fear of
affecting other scripts' results.  Also, our former habit of declaring
all C functions in one place is now gone in favor of declaring them
where they're used, if that's just one script, or in test_setup if
necessary.

There's more that could be done to remove some of the remaining
inter-script dependencies, but significantly more-invasive changes
would be needed, and at least for now it doesn't seem worth it.

Discussion: https://postgr.es/m/1114748.1640383217@sss.pgh.pa.us
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The idea behind this patch is to make it possible to run individual
test scripts without running the entire core test suite.  Making all
the scripts completely independent would involve a massive rewrite,
and would probably be worse for coverage of things like concurrent DDL.
So this patch just does what seems practical with limited changes.

The net effect is that any test script can be run after running
limited earlier dependencies:
* all scripts depend on test_setup
* many scripts depend on create_index
* other dependencies are few in number, and are documented in
  the parallel_schedule file.

To accomplish this, I chose a small number of commonly-used tables
and moved their creation and filling into test_setup.  Later scripts
are expected not to modify these tables' data contents, for fear of
affecting other scripts' results.  Also, our former habit of declaring
all C functions in one place is now gone in favor of declaring them
where they're used, if that's just one script, or in test_setup if
necessary.

There's more that could be done to remove some of the remaining
inter-script dependencies, but significantly more-invasive changes
would be needed, and at least for now it doesn't seem worth it.

Discussion: https://postgr.es/m/1114748.1640383217@sss.pgh.pa.us
</pre>
</div>
</content>
</entry>
<entry>
<title>Clean up ancient test style</title>
<updated>2020-12-15T21:03:39+00:00</updated>
<author>
<name>Peter Eisentraut</name>
<email>peter@eisentraut.org</email>
</author>
<published>2020-12-15T20:54:06+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=c06d6aa4c35177655e0fd4acaca888a73c3f9845'/>
<id>c06d6aa4c35177655e0fd4acaca888a73c3f9845</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Add functions gcd() and lcm() for integer and numeric types.</title>
<updated>2020-01-25T14:00:59+00:00</updated>
<author>
<name>Dean Rasheed</name>
<email>dean.a.rasheed@gmail.com</email>
</author>
<published>2020-01-25T14:00:59+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=13661ddd7eaec7e2809ff5c29fc14653b6161036'/>
<id>13661ddd7eaec7e2809ff5c29fc14653b6161036</id>
<content type='text'>
These compute the greatest common divisor and least common multiple of
a pair of numbers using the Euclidean algorithm.

Vik Fearing, reviewed by Fabien Coelho.

Discussion: https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These compute the greatest common divisor and least common multiple of
a pair of numbers using the Euclidean algorithm.

Vik Fearing, reviewed by Fabien Coelho.

Discussion: https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Change floating-point output format for improved performance.</title>
<updated>2019-02-13T15:20:33+00:00</updated>
<author>
<name>Andrew Gierth</name>
<email>rhodiumtoad@postgresql.org</email>
</author>
<published>2019-02-13T15:20:33+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=02ddd499322ab6f2f0d58692955dc9633c2150fc'/>
<id>02ddd499322ab6f2f0d58692955dc9633c2150fc</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Deduplicate "invalid input syntax" messages for various types.</title>
<updated>2018-07-22T21:58:01+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2018-07-22T21:58:01+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=3522d0eaba5a976f09a48810dd25dff6ab3565df'/>
<id>3522d0eaba5a976f09a48810dd25dff6ab3565df</id>
<content type='text'>
Previously a lot of the error messages referenced the type in the
error message itself. That requires that the message is translated
separately for each type.

Note that currently a few smallint cases continue to reference the
integer, rather than smallint, type. A later patch will create a
separate routine for 16bit input.

Author: Andres Freund
Discussion: https://postgr.es/m/20180707200158.wpqkd7rjr4jxq5g7@alap3.anarazel.de
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously a lot of the error messages referenced the type in the
error message itself. That requires that the message is translated
separately for each type.

Note that currently a few smallint cases continue to reference the
integer, rather than smallint, type. A later patch will create a
separate routine for 16bit input.

Author: Andres Freund
Discussion: https://postgr.es/m/20180707200158.wpqkd7rjr4jxq5g7@alap3.anarazel.de
</pre>
</div>
</content>
</entry>
<entry>
<title>Add documentation and regression tests concerning rounding of numerics.</title>
<updated>2015-07-03T21:04:39+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2015-07-03T21:04:39+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=5e7c3d91bf24a212b42c912234c6cb37d75e0292'/>
<id>5e7c3d91bf24a212b42c912234c6cb37d75e0292</id>
<content type='text'>
Michael Paquier, reviewed by Fabien Coelho
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Michael Paquier, reviewed by Fabien Coelho
</pre>
</div>
</content>
</entry>
</feed>
