opensourcemirror
/
postgresql
mirror of git://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Releases Wiki Activity
postgresql/src/backend/utils/adt/float.c

3915 lines
89 KiB
C
Raw Normal View History

Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*-------------------------------------------------------------------------
*
Change my-function-name-- to my_function_name, and optimizer renames.
1999-02-14 00:22:53 +01:00
* float.c
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* Functions for the built-in floating-point types.
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
Update copyright for 2019 Backpatch-through: certain files through 9.4
2019-01-02 18:44:25 +01:00
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
Add: * Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
2000-01-26 06:58:53 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
*
* IDENTIFICATION
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/backend/utils/adt/float.c
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*
*-------------------------------------------------------------------------
*/
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
#include "postgres.h"
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#include <ctype.h>
Add #include <float.h> for platforms that still need it.
2007-01-02 21:50:35 +01:00
#include <float.h>
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
#include <math.h>
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
#include <limits.h>
Big warnings cleanup for Solaris/GCC. Down to about 40 now, but we'll get there one day. Use `cat' to create aclocal.m4, not `aclocal'. Some people don't have automake installed. Only run the autoconf rule in the top-level GNUmakefile if the invoker specified `make configure', don't run it automatically because of CVS timestamp skew.
2000-06-14 20:18:01 +02:00
Modify array operations to include array's element type OID in the array header, and to compute sizing and alignment of array elements the same way normal tuple access operations do --- viz, using the tupmacs.h macros att_addlength and att_align. This makes the world safe for arrays of cstrings or intervals, and should make it much easier to write array-type-polymorphic functions; as examples see the cleanups of array_out and contrib/array_iterator. By Joe Conway and Tom Lane.
2002-08-26 19:54:02 +02:00
#include "catalog/pg_type.h"
Use new overflow aware integer operations. A previous commit added inline functions that provide fast(er) and correct overflow checks for signed integer math. Use them in a significant portion of backend code. There's more to touch in both backend and frontend code, but these were the easily identifiable cases. The old overflow checks are noticeable in integer heavy workloads. A secondary benefit is that getting rid of overflow checks that rely on signed integer overflow wrapping around, will allow us to get rid of -fwrapv in the future. Which in turn slows down other code. Author: Andres Freund Discussion: https://postgr.es/m/20171024103954.ztmatprlglz3rwke@alap3.anarazel.de
2017-12-13 01:32:31 +01:00
#include "common/int.h"
Change floating-point output format for improved performance. Previously, floating-point output was done by rounding to a specific decimal precision; by default, to 6 or 15 decimal digits (losing information) or as requested using extra_float_digits. Drivers that wanted exact float values, and applications like pg_dump that must preserve values exactly, set extra_float_digits=3 (or sometimes 2 for historical reasons, though this isn't enough for float4). Unfortunately, decimal rounded output is slow enough to become a noticable bottleneck when dealing with large result sets or COPY of large tables when many floating-point values are involved. Floating-point output can be done much faster when the output is not rounded to a specific decimal length, but rather is chosen as the shortest decimal representation that is closer to the original float value than to any other value representable in the same precision. The recently published Ryu algorithm by Ulf Adams is both relatively simple and remarkably fast. Accordingly, change float4out/float8out to output shortest decimal representations if extra_float_digits is greater than 0, and make that the new default. Applications that need rounded output can set extra_float_digits back to 0 or below, and take the resulting performance hit. We make one concession to portability for systems with buggy floating-point input: we do not output decimal values that fall exactly halfway between adjacent representable binary values (which would rely on the reader doing round-to-nearest-even correctly). This is known to be a problem at least for VS2013 on Windows. Our version of the Ryu code originates from https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the following (significant) modifications: - Output format is changed to use fixed-point notation for small exponents, as printf would, and also to use lowercase 'e', a minimum of 2 exponent digits, and a mandatory sign on the exponent, to keep the formatting as close as possible to previous output. - The output of exact midpoint values is disabled as noted above. - The integer fast-path code is changed somewhat (since we have fixed-point output and the upstream did not). - Our project style has been largely applied to the code with the exception of C99 declaration-after-statement, which has been retained as an exception to our present policy. - Most of upstream's debugging and conditionals are removed, and we use our own configure tests to determine things like uint128 availability. Changing the float output format obviously affects a number of regression tests. This patch uses an explicit setting of extra_float_digits=0 for test output that is not expected to be exactly reproducible (e.g. due to numerical instability or differing algorithms for transcendental functions). Conversions from floats to numeric are unchanged by this patch. These may appear in index expressions and it is not yet clear whether any change should be made, so that can be left for another day. This patch assumes that the only supported floating point format is now IEEE format, and the documentation is updated to reflect that. Code by me, adapting the work of Ulf Adams and other contributors. References: https://dl.acm.org/citation.cfm?id=3192369 Reviewed-by: Tom Lane, Andres Freund, Donald Dong Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
#include "common/shortest_dec.h"
COPY BINARY uses the new binary I/O routines. Update a few more datatypes so that COPY BINARY regression test passes.
2003-05-09 23:19:50 +02:00
#include "libpq/pqformat.h"
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
#include "miscadmin.h"
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
#include "utils/array.h"
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
#include "utils/float.h"
#include "utils/fmgrprotos.h"
Create a "sort support" interface API for faster sorting. This patch creates an API whereby a btree index opclass can optionally provide non-SQL-callable support functions for sorting. In the initial patch, we only use this to provide a directly-callable comparator function, which can be invoked with a bit less overhead than the traditional SQL-callable comparator. While that should be of value in itself, the real reason for doing this is to provide a datatype-extensible framework for more aggressive optimizations, as in Peter Geoghegan's recent work. Robert Haas and Tom Lane
2011-12-07 06:18:38 +01:00
#include "utils/sortsupport.h"
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
#include "utils/timestamp.h"
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Change floating-point output format for improved performance. Previously, floating-point output was done by rounding to a specific decimal precision; by default, to 6 or 15 decimal digits (losing information) or as requested using extra_float_digits. Drivers that wanted exact float values, and applications like pg_dump that must preserve values exactly, set extra_float_digits=3 (or sometimes 2 for historical reasons, though this isn't enough for float4). Unfortunately, decimal rounded output is slow enough to become a noticable bottleneck when dealing with large result sets or COPY of large tables when many floating-point values are involved. Floating-point output can be done much faster when the output is not rounded to a specific decimal length, but rather is chosen as the shortest decimal representation that is closer to the original float value than to any other value representable in the same precision. The recently published Ryu algorithm by Ulf Adams is both relatively simple and remarkably fast. Accordingly, change float4out/float8out to output shortest decimal representations if extra_float_digits is greater than 0, and make that the new default. Applications that need rounded output can set extra_float_digits back to 0 or below, and take the resulting performance hit. We make one concession to portability for systems with buggy floating-point input: we do not output decimal values that fall exactly halfway between adjacent representable binary values (which would rely on the reader doing round-to-nearest-even correctly). This is known to be a problem at least for VS2013 on Windows. Our version of the Ryu code originates from https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the following (significant) modifications: - Output format is changed to use fixed-point notation for small exponents, as printf would, and also to use lowercase 'e', a minimum of 2 exponent digits, and a mandatory sign on the exponent, to keep the formatting as close as possible to previous output. - The output of exact midpoint values is disabled as noted above. - The integer fast-path code is changed somewhat (since we have fixed-point output and the upstream did not). - Our project style has been largely applied to the code with the exception of C99 declaration-after-statement, which has been retained as an exception to our present policy. - Most of upstream's debugging and conditionals are removed, and we use our own configure tests to determine things like uint128 availability. Changing the float output format obviously affects a number of regression tests. This patch uses an explicit setting of extra_float_digits=0 for test output that is not expected to be exactly reproducible (e.g. due to numerical instability or differing algorithms for transcendental functions). Conversions from floats to numeric are unchanged by this patch. These may appear in index expressions and it is not yet clear whether any change should be made, so that can be left for another day. This patch assumes that the only supported floating point format is now IEEE format, and the documentation is updated to reflect that. Code by me, adapting the work of Ulf Adams and other contributors. References: https://dl.acm.org/citation.cfm?id=3192369 Reviewed-by: Tom Lane, Andres Freund, Donald Dong Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
/*
* Configurable GUC parameter
*
* If >0, use shortest-decimal format for output; this is both the default and
* allows for compatibility with clients that explicitly set a value here to
* get round-trip-accurate results. If 0 or less, then use the old, slow,
* decimal rounding method.
*/
int extra_float_digits = 1;
Add extra_float_digits GUC parameter to allow adjustment of displayed precision for float4, float8, and geometric types. Set it in pg_dump so that float data can be dumped/reloaded exactly (at least on platforms where the float I/O support is properly implemented). Initial patch by Pedro Ferreira, some additional work by Tom Lane.
2002-11-08 18:37:52 +01:00
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
/* Cached constants for degree-based trig functions */
static bool degree_consts_set = false;
static float8 sin_30 = 0;
static float8 one_minus_cos_60 = 0;
static float8 asin_0_5 = 0;
static float8 acos_0_5 = 0;
static float8 atan_1_0 = 0;
static float8 tan_45 = 0;
static float8 cot_45 = 0;
New method for preventing compile-time calculation of degree constants. Commit 65abaab547a5758b tried to prevent the scaling constants used in the degree-based trig functions from being precomputed at compile time, because some compilers do that with functions that don't yield results identical-to-the-last-bit to what you get at runtime. A report from Peter Eisentraut suggests that some recent compilers are smart enough to see through that trick, though. Instead, let's put the inputs to these calculations into non-const global variables, which should be a more reliable way of convincing the compiler that it can't assume that they are compile-time constants. (If we really get desperate, we could mark these variables "volatile", but I do not believe we should have to.)
2016-04-25 21:21:04 +02:00
/*
* These are intentionally not static; don't "fix" them. They will never
* be referenced by other files, much less changed; but we don't want the
* compiler to know that, else it might try to precompute expressions
* involving them. See comments for init_degree_constants().
*/
float8 degree_c_thirty = 30.0;
float8 degree_c_forty_five = 45.0;
float8 degree_c_sixty = 60.0;
float8 degree_c_one_half = 0.5;
float8 degree_c_one = 1.0;
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
/* State for drandom() and setseed() */
static bool drandom_seed_set = false;
static unsigned short drandom_seed[3] = {0, 0, 0};
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
/* Local function prototypes */
static double sind_q1(double x);
static double cosd_q1(double x);
New method for preventing compile-time calculation of degree constants. Commit 65abaab547a5758b tried to prevent the scaling constants used in the degree-based trig functions from being precomputed at compile time, because some compilers do that with functions that don't yield results identical-to-the-last-bit to what you get at runtime. A report from Peter Eisentraut suggests that some recent compilers are smart enough to see through that trick, though. Instead, let's put the inputs to these calculations into non-const global variables, which should be a more reliable way of convincing the compiler that it can't assume that they are compile-time constants. (If we really get desperate, we could mark these variables "volatile", but I do not believe we should have to.)
2016-04-25 21:21:04 +02:00
static void init_degree_constants(void);
Still further adjust degree-based trig functions for more portability. Indeed, the non-static declaration foreseen in my previous commit message is necessary. Per Noah Misch.
2016-01-24 00:12:54 +01:00
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
#ifndef HAVE_CBRT
Put back our old workaround for machines that declare cbrt() in math.h but fail to provide the function itself. Not sure how we escaped testing anything later than 7.3 on such cases, but they still exist, as per André Volpato's report about AIX 5.3.
2009-03-04 23:08:20 +01:00
/*
* Some machines (in particular, some versions of AIX) have an extern
* declaration for cbrt() in <math.h> but fail to provide the actual
* function, which causes configure to not set HAVE_CBRT. Furthermore,
* their compilers spit up at the mismatch between extern declaration
* and static definition. We work around that here by the expedient
* of a #define to make the actual name of the static function different.
*/
#define cbrt my_cbrt
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
static double cbrt(double x);
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* HAVE_CBRT */
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
/*
* Returns -1 if 'val' represents negative infinity, 1 if 'val'
* represents (positive) infinity, and 0 otherwise. On some platforms,
* this is equivalent to the isinf() macro, but not everywhere: C99
* does not specify that isinf() needs to distinguish between positive
* and negative infinity.
*/
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
int
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
is_infinite(double val)
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int inf = isinf(val);
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
if (inf == 0)
return 0;
finite() no longer used; remove finite() platform-specific infrastructure.
2007-01-02 22:25:50 +01:00
else if (val > 0)
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
return 1;
finite() no longer used; remove finite() platform-specific infrastructure.
2007-01-02 22:25:50 +01:00
else
return -1;
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
}
Add extra_float_digits GUC parameter to allow adjustment of displayed precision for float4, float8, and geometric types. Set it in pg_dump so that float data can be dumped/reloaded exactly (at least on platforms where the float I/O support is properly implemented). Initial patch by Pedro Ferreira, some additional work by Tom Lane.
2002-11-08 18:37:52 +01:00
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
/* ========== USER I/O ROUTINES ========== */
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
* float4in - converts "num" to float4
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
*
* Note that this code now uses strtof(), where it used to use strtod().
*
* The motivation for using strtof() is to avoid a double-rounding problem:
* for certain decimal inputs, if you round the input correctly to a double,
* and then round the double to a float, the result is incorrect in that it
* does not match the result of rounding the decimal value to float directly.
*
* One of the best examples is 7.038531e-26:
*
* 0xAE43FDp-107 = 7.03853069185120912085...e-26
* midpoint 7.03853100000000022281...e-26
* 0xAE43FEp-107 = 7.03853130814879132477...e-26
*
* making 0xAE43FDp-107 the correct float result, but if you do the conversion
* via a double, you get
*
* 0xAE43FD.7FFFFFF8p-107 = 7.03853099999999907487...e-26
* midpoint 7.03853099999999964884...e-26
* 0xAE43FD.80000000p-107 = 7.03853100000000022281...e-26
* 0xAE43FD.80000008p-107 = 7.03853100000000137076...e-26
*
* so the value rounds to the double exactly on the midpoint between the two
* nearest floats, and then rounding again to a float gives the incorrect
* result of 0xAE43FEp-107.
*
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4in(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
char *num = PG_GETARG_CSTRING(0);
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
char *orig_num;
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
float val;
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
char *endptr;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* endptr points to the first character _after_ the sequence we recognized
* as a valid floating point number. orig_num points to the original input
* string.
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
*/
orig_num = num;
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
/* skip leading whitespace */
while (*num != '\0' && isspace((unsigned char) *num))
num++;
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check for an empty-string input to begin with, to avoid the vagaries of
* strtod() on different platforms.
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
*/
if (*num == '\0')
Adjust input routines for float4, float8 and oid to reject the empty string as valid input (it was previously treated as 0). This input was deprecated in 8.0 (and a warning was emitted). Regression tests updated.
2005-02-11 05:09:05 +01:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
Make messages mentioning type names more uniform This avoids additional translatable strings for each distinct type, as well as making our quoting style around type names more consistent (namely, that we don't quote type names). This continues what started as f402b9950120. Discussion: https://postgr.es/m/20160401170642.GA57509@alvherre.pgsql
2017-01-18 20:08:20 +01:00
errmsg("invalid input syntax for type %s: \"%s\"",
"real", orig_num)));
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
Remove comment on errno=0 lines, but add mention to port/strtol.c function.
2005-12-02 03:49:11 +01:00
errno = 0;
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
val = strtof(num, &endptr);
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
/* did we not see anything that looks like a double? */
Fix some portability issues with new float input code (didn't work on HPUX 11 ...)
2004-04-02 01:52:18 +02:00
if (endptr == num || errno != 0)
Improper addition of NaN/Infinity recognition to float8in() was causing it not to detect out-of-range float values, as evidenced by failure of float8 regression test. I corrected that logic and also modified expected float8 results to account for new error message generated for out-of-range inputs.
1999-01-24 01:12:59 +01:00
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
int save_errno = errno;
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
Accept and output '-Infinity' as well as 'Infinity', per long-ago suggestion from Ross Reedstrom. Still needs work to make those symbols convert to actual IEEE infinities (on machines where such things exist).
2001-06-02 22:18:30 +02:00
/*
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
* C99 requires that strtof() accept NaN, [+-]Infinity, and [+-]Inf,
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
* but not all platforms support all of these (and some accept them
* but set ERANGE anyway...) Therefore, we check for these inputs
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
* ourselves if strtof() fails.
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
*
* Note: C99 also requires hexadecimal input as well as some extended
* forms of NaN, but we consider these forms unportable and don't try
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
* to support them. You can use 'em if your strtof() takes 'em.
Accept and output '-Infinity' as well as 'Infinity', per long-ago suggestion from Ross Reedstrom. Still needs work to make those symbols convert to actual IEEE infinities (on machines where such things exist).
2001-06-02 22:18:30 +02:00
*/
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
if (pg_strncasecmp(num, "NaN", 3) == 0)
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
{
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
val = get_float4_nan();
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
endptr = num + 3;
}
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strncasecmp(num, "Infinity", 8) == 0)
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
{
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
val = get_float4_infinity();
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
endptr = num + 8;
}
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
else if (pg_strncasecmp(num, "+Infinity", 9) == 0)
{
val = get_float4_infinity();
endptr = num + 9;
}
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strncasecmp(num, "-Infinity", 9) == 0)
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
val = -get_float4_infinity();
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
endptr = num + 9;
}
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
else if (pg_strncasecmp(num, "inf", 3) == 0)
{
val = get_float4_infinity();
endptr = num + 3;
}
else if (pg_strncasecmp(num, "+inf", 4) == 0)
{
val = get_float4_infinity();
endptr = num + 4;
}
else if (pg_strncasecmp(num, "-inf", 4) == 0)
{
val = -get_float4_infinity();
endptr = num + 4;
}
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
else if (save_errno == ERANGE)
{
/*
* Some platforms return ERANGE for denormalized numbers (those
* that are not zero, but are too close to zero to have full
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* precision). We'd prefer not to throw error for that, so try to
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* detect whether it's a "real" out-of-range condition by checking
* to see if the result is zero or huge.
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
*
Add support for hyperbolic functions, as well as log10(). The SQL:2016 standard adds support for the hyperbolic functions sinh(), cosh(), and tanh(). POSIX has long required libm to provide those functions as well as their inverses asinh(), acosh(), atanh(). Hence, let's just expose the libm functions to the SQL level. As with the trig functions, we only implement versions for float8, not numeric. For the moment, we'll assume that all platforms actually do have these functions; if experience teaches otherwise, some autoconf effort may be needed. SQL:2016 also adds support for base-10 logarithm, but with the function name log10(), whereas the name we've long used is log(). Add aliases named log10() for the float8 and numeric versions. Lætitia Avrot Discussion: https://postgr.es/m/CAB_COdguG22LO=rnxDQ2DW1uzv8aQoUzyDQNJjrR4k00XSgm5w@mail.gmail.com
2019-03-12 20:55:09 +01:00
* Use isinf() rather than HUGE_VALF on VS2013 because it
* generates a spurious overflow warning for -HUGE_VALF. Also use
* isinf() if HUGE_VALF is missing.
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
*/
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
if (val == 0.0 ||
#if !defined(HUGE_VALF) || (defined(_MSC_VER) && (_MSC_VER < 1900))
isinf(val)
#else
(val >= HUGE_VALF || val <= -HUGE_VALF)
#endif
)
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("\"%s\" is out of range for type real",
orig_num)));
}
Accept and output '-Infinity' as well as 'Infinity', per long-ago suggestion from Ross Reedstrom. Still needs work to make those symbols convert to actual IEEE infinities (on machines where such things exist).
2001-06-02 22:18:30 +02:00
else
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
Make messages mentioning type names more uniform This avoids additional translatable strings for each distinct type, as well as making our quoting style around type names more consistent (namely, that we don't quote type names). This continues what started as f402b9950120. Discussion: https://postgr.es/m/20160401170642.GA57509@alvherre.pgsql
2017-01-18 20:08:20 +01:00
errmsg("invalid input syntax for type %s: \"%s\"",
"real", orig_num)));
Improper addition of NaN/Infinity recognition to float8in() was causing it not to detect out-of-range float values, as evidenced by failure of float8 regression test. I corrected that logic and also modified expected float8 results to account for new error message generated for out-of-range inputs.
1999-01-24 01:12:59 +01:00
}
Work around broken strtod() that's present in many Solaris releases. Thanks to Michael Fuhr for identifying the problem.
2004-08-11 19:20:50 +02:00
#ifdef HAVE_BUGGY_SOLARIS_STRTOD
else
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Many versions of Solaris have a bug wherein strtod sets endptr to
* point one byte beyond the end of the string when given "inf" or
* "infinity".
Work around broken strtod() that's present in many Solaris releases. Thanks to Michael Fuhr for identifying the problem.
2004-08-11 19:20:50 +02:00
*/
if (endptr != num && endptr[-1] == '\0')
endptr--;
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* HAVE_BUGGY_SOLARIS_STRTOD */
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
/* skip trailing whitespace */
Add missing casts to unsigned char in recently-added isspace() calls.
2004-04-02 00:51:31 +02:00
while (*endptr != '\0' && isspace((unsigned char) *endptr))
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
endptr++;
/* if there is any junk left at the end of the string, bail out */
if (*endptr != '\0')
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
Make messages mentioning type names more uniform This avoids additional translatable strings for each distinct type, as well as making our quoting style around type names more consistent (namely, that we don't quote type names). This continues what started as f402b9950120. Discussion: https://postgr.es/m/20160401170642.GA57509@alvherre.pgsql
2017-01-18 20:08:20 +01:00
errmsg("invalid input syntax for type %s: \"%s\"",
"real", orig_num)));
Emit a warning when an empty string is input to the oid, float4, and float8 types. This begins the deprecation of this feature: in 7.6, this input will be rejected. Also added a new error code for warnings about deprecated features, and updated the regression tests.
2004-03-04 22:47:18 +01:00
Use strtof() and not strtod() for float4 input. Using strtod() creates a double-rounding problem; the input decimal value is first rounded to the nearest double; rounding that to the nearest float may then give an incorrect result. An example is that 7.038531e-26 when input via strtod and then rounded to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107. Values output by earlier PG versions with extra_float_digits=3 should all be read in with the same values as previously. However, values supplied by other software using shortest representations could be mis-read. On platforms that lack a strtof() entirely, we fall back to the old incorrect rounding behavior. (As strtof() is required by C99, such platforms are considered of primarily historical interest.) On VS2013, some workarounds are used to get correct error handling. The regression tests now test for the correct input values, so platforms that lack strtof() will need resultmap entries. An entry for HP-UX 10 is included (more may be needed). Reviewed-By: Tom Lane Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
2019-02-13 16:19:44 +01:00
PG_RETURN_FLOAT4(val);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* float4out - converts a float4 number to a string
* using a standard output format
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4out(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 num = PG_GETARG_FLOAT4(0);
Improve snprintf.c's handling of NaN, Infinity, and minus zero. Up to now, float4out/float8out handled NaN and Infinity cases explicitly, and invoked psprintf only for ordinary float values. This was done because platform implementations of snprintf produce varying representations of these special cases. But now that we use snprintf.c always, it's better to give it the responsibility to produce a uniform representation of these cases, so that we have uniformity across the board not only in float4out/float8out. Hence, move that work into fmtfloat(). Also, teach fmtfloat() to recognize IEEE minus zero and handle it correctly. The previous coding worked only accidentally, and would fail for e.g. "%+f" format (it'd print "+-0.00000"). Now that we're using snprintf.c everywhere, it's not acceptable for it to do weird things in corner cases. (This incidentally avoids a portability problem we've seen on some really ancient platforms, that native sprintf does the wrong thing with minus zero.) Also, introduce a new entry point in snprintf.c to allow float[48]out to bypass the work of interpreting a well-known format spec, as well as bypassing the overhead of the psprintf layer. I modeled this API loosely on strfromd(). In my testing, this brings float[48]out back to approximately the same speed they had when using native snprintf, fixing one of the main performance issues caused by using snprintf.c. (There is some talk of more aggressive work to improve the speed of floating-point output conversion, but these changes seem to provide a better starting point for such work anyway.) Getting rid of the previous ad-hoc hack for Infinity/NaN in fmtfloat() allows removing <ctype.h> from snprintf.c's #includes. I also removed a few other #includes that I think are historical, though the buildfarm may expose that as wrong. Discussion: https://postgr.es/m/13178.1538794717@sss.pgh.pa.us
2018-10-08 18:19:20 +02:00
char *ascii = (char *) palloc(32);
int ndig = FLT_DIG + extra_float_digits;
Add extra_float_digits GUC parameter to allow adjustment of displayed precision for float4, float8, and geometric types. Set it in pg_dump so that float data can be dumped/reloaded exactly (at least on platforms where the float I/O support is properly implemented). Initial patch by Pedro Ferreira, some additional work by Tom Lane.
2002-11-08 18:37:52 +01:00
Change floating-point output format for improved performance. Previously, floating-point output was done by rounding to a specific decimal precision; by default, to 6 or 15 decimal digits (losing information) or as requested using extra_float_digits. Drivers that wanted exact float values, and applications like pg_dump that must preserve values exactly, set extra_float_digits=3 (or sometimes 2 for historical reasons, though this isn't enough for float4). Unfortunately, decimal rounded output is slow enough to become a noticable bottleneck when dealing with large result sets or COPY of large tables when many floating-point values are involved. Floating-point output can be done much faster when the output is not rounded to a specific decimal length, but rather is chosen as the shortest decimal representation that is closer to the original float value than to any other value representable in the same precision. The recently published Ryu algorithm by Ulf Adams is both relatively simple and remarkably fast. Accordingly, change float4out/float8out to output shortest decimal representations if extra_float_digits is greater than 0, and make that the new default. Applications that need rounded output can set extra_float_digits back to 0 or below, and take the resulting performance hit. We make one concession to portability for systems with buggy floating-point input: we do not output decimal values that fall exactly halfway between adjacent representable binary values (which would rely on the reader doing round-to-nearest-even correctly). This is known to be a problem at least for VS2013 on Windows. Our version of the Ryu code originates from https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the following (significant) modifications: - Output format is changed to use fixed-point notation for small exponents, as printf would, and also to use lowercase 'e', a minimum of 2 exponent digits, and a mandatory sign on the exponent, to keep the formatting as close as possible to previous output. - The output of exact midpoint values is disabled as noted above. - The integer fast-path code is changed somewhat (since we have fixed-point output and the upstream did not). - Our project style has been largely applied to the code with the exception of C99 declaration-after-statement, which has been retained as an exception to our present policy. - Most of upstream's debugging and conditionals are removed, and we use our own configure tests to determine things like uint128 availability. Changing the float output format obviously affects a number of regression tests. This patch uses an explicit setting of extra_float_digits=0 for test output that is not expected to be exactly reproducible (e.g. due to numerical instability or differing algorithms for transcendental functions). Conversions from floats to numeric are unchanged by this patch. These may appear in index expressions and it is not yet clear whether any change should be made, so that can be left for another day. This patch assumes that the only supported floating point format is now IEEE format, and the documentation is updated to reflect that. Code by me, adapting the work of Ulf Adams and other contributors. References: https://dl.acm.org/citation.cfm?id=3192369 Reviewed-by: Tom Lane, Andres Freund, Donald Dong Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
if (extra_float_digits > 0)
{
float_to_shortest_decimal_buf(num, ascii);
PG_RETURN_CSTRING(ascii);
}
Improve snprintf.c's handling of NaN, Infinity, and minus zero. Up to now, float4out/float8out handled NaN and Infinity cases explicitly, and invoked psprintf only for ordinary float values. This was done because platform implementations of snprintf produce varying representations of these special cases. But now that we use snprintf.c always, it's better to give it the responsibility to produce a uniform representation of these cases, so that we have uniformity across the board not only in float4out/float8out. Hence, move that work into fmtfloat(). Also, teach fmtfloat() to recognize IEEE minus zero and handle it correctly. The previous coding worked only accidentally, and would fail for e.g. "%+f" format (it'd print "+-0.00000"). Now that we're using snprintf.c everywhere, it's not acceptable for it to do weird things in corner cases. (This incidentally avoids a portability problem we've seen on some really ancient platforms, that native sprintf does the wrong thing with minus zero.) Also, introduce a new entry point in snprintf.c to allow float[48]out to bypass the work of interpreting a well-known format spec, as well as bypassing the overhead of the psprintf layer. I modeled this API loosely on strfromd(). In my testing, this brings float[48]out back to approximately the same speed they had when using native snprintf, fixing one of the main performance issues caused by using snprintf.c. (There is some talk of more aggressive work to improve the speed of floating-point output conversion, but these changes seem to provide a better starting point for such work anyway.) Getting rid of the previous ad-hoc hack for Infinity/NaN in fmtfloat() allows removing <ctype.h> from snprintf.c's #includes. I also removed a few other #includes that I think are historical, though the buildfarm may expose that as wrong. Discussion: https://postgr.es/m/13178.1538794717@sss.pgh.pa.us
2018-10-08 18:19:20 +02:00
(void) pg_strfromd(ascii, 32, ndig, num);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_CSTRING(ascii);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
COPY BINARY uses the new binary I/O routines. Update a few more datatypes so that COPY BINARY regression test passes.
2003-05-09 23:19:50 +02:00
/*
* float4recv - converts external binary format to float4
*/
Datum
float4recv(PG_FUNCTION_ARGS)
{
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
PG_RETURN_FLOAT4(pq_getmsgfloat4(buf));
}
/*
* float4send - converts float4 to binary format
*/
Datum
float4send(PG_FUNCTION_ARGS)
{
float4 num = PG_GETARG_FLOAT4(0);
StringInfoData buf;
pq_begintypsend(&buf);
pq_sendfloat4(&buf, num);
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* float8in - converts "num" to float8
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8in(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
char *num = PG_GETARG_CSTRING(0);
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
PG_RETURN_FLOAT8(float8in_internal(num, NULL, "double precision", num));
}
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
/* Convenience macro: set *have_error flag (if provided) or throw error */
Add safeguards in LSN, numeric and float calculation for custom errors Those data types use parsing and/or calculation wrapper routines which can generate some generic error messages in the event of a failure. The caller of these routines can also pass a pointer variable settable by the routine to track if an error has happened, letting the caller decide what to do in the event of an error and what error message to generate. Those routines have been slacking the initialization of the tracking flag, which can be confusing when reading the code, so add some safeguards against calls of these parsing routines which could lead to a dubious result. The LSN parsing gains an assertion to make sure that the tracking flag is set, while numeric and float paths initialize the flag to a saner state. Author: Jeevan Ladhe Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com
2019-08-05 08:35:16 +02:00
#define RETURN_ERROR(throw_error, have_error) \
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
do { \
if (have_error) { \
*have_error = true; \
return 0.0; \
} else { \
throw_error; \
} \
} while (0)
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
/*
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
* float8in_internal_opt_error - guts of float8in()
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
*
* This is exposed for use by functions that want a reasonably
* platform-independent way of inputting doubles. The behavior is
* essentially like strtod + ereport on error, but note the following
* differences:
* 1. Both leading and trailing whitespace are skipped.
* 2. If endptr_p is NULL, we throw error if there's trailing junk.
* Otherwise, it's up to the caller to complain about trailing junk.
* 3. In event of a syntax error, the report mentions the given type_name
* and prints orig_string as the input; this is meant to support use of
* this function with types such as "box" and "point", where what we are
* parsing here is just a substring of orig_string.
*
* "num" could validly be declared "const char *", but that results in an
* unreasonable amount of extra casting both here and in callers, so we don't.
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
*
* When "*have_error" flag is provided, it's set instead of throwing an
* error. This is helpful when caller need to handle errors by itself.
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
*/
double
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
float8in_internal_opt_error(char *num, char **endptr_p,
const char *type_name, const char *orig_string,
bool *have_error)
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
{
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
double val;
char *endptr;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Add safeguards in LSN, numeric and float calculation for custom errors Those data types use parsing and/or calculation wrapper routines which can generate some generic error messages in the event of a failure. The caller of these routines can also pass a pointer variable settable by the routine to track if an error has happened, letting the caller decide what to do in the event of an error and what error message to generate. Those routines have been slacking the initialization of the tracking flag, which can be confusing when reading the code, so add some safeguards against calls of these parsing routines which could lead to a dubious result. The LSN parsing gains an assertion to make sure that the tracking flag is set, while numeric and float paths initialize the flag to a saner state. Author: Jeevan Ladhe Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com
2019-08-05 08:35:16 +02:00
if (have_error)
*have_error = false;
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
/* skip leading whitespace */
while (*num != '\0' && isspace((unsigned char) *num))
num++;
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check for an empty-string input to begin with, to avoid the vagaries of
* strtod() on different platforms.
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
*/
if (*num == '\0')
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
RETURN_ERROR(ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("invalid input syntax for type %s: \"%s\"",
Add safeguards in LSN, numeric and float calculation for custom errors Those data types use parsing and/or calculation wrapper routines which can generate some generic error messages in the event of a failure. The caller of these routines can also pass a pointer variable settable by the routine to track if an error has happened, letting the caller decide what to do in the event of an error and what error message to generate. Those routines have been slacking the initialization of the tracking flag, which can be confusing when reading the code, so add some safeguards against calls of these parsing routines which could lead to a dubious result. The LSN parsing gains an assertion to make sure that the tracking flag is set, while numeric and float paths initialize the flag to a saner state. Author: Jeevan Ladhe Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com
2019-08-05 08:35:16 +02:00
type_name, orig_string))),
have_error);
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
Remove comment on errno=0 lines, but add mention to port/strtol.c function.
2005-12-02 03:49:11 +01:00
errno = 0;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
val = strtod(num, &endptr);
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
/* did we not see anything that looks like a double? */
Fix some portability issues with new float input code (didn't work on HPUX 11 ...)
2004-04-02 01:52:18 +02:00
if (endptr == num || errno != 0)
Handle "NaN" and "Infinity" for input values. I think NAN is already guaranteed to be there from Jan's work on NUMERIC, but perhaps HUGE_VAL needs some #ifndef's in the same place. Should also include "-Infinity" as -HUGE_VAL sometime; not there yet.
1999-01-10 18:13:06 +01:00
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
int save_errno = errno;
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
/*
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
* C99 requires that strtod() accept NaN, [+-]Infinity, and [+-]Inf,
* but not all platforms support all of these (and some accept them
* but set ERANGE anyway...) Therefore, we check for these inputs
* ourselves if strtod() fails.
*
* Note: C99 also requires hexadecimal input as well as some extended
* forms of NaN, but we consider these forms unportable and don't try
* to support them. You can use 'em if your strtod() takes 'em.
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
*/
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
if (pg_strncasecmp(num, "NaN", 3) == 0)
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
{
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
val = get_float8_nan();
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
endptr = num + 3;
}
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strncasecmp(num, "Infinity", 8) == 0)
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
{
Localize our dependencies on the way to create NAN or INFINITY. Per recent proposal to pghackers.
2004-03-15 04:29:22 +01:00
val = get_float8_infinity();
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
endptr = num + 8;
}
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
else if (pg_strncasecmp(num, "+Infinity", 9) == 0)
{
val = get_float8_infinity();
endptr = num + 9;
}
Solve the 'Turkish problem' with undesirable locale behavior for case conversion of basic ASCII letters. Remove all uses of strcasecmp and strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp; remove most but not all direct uses of toupper and tolower in favor of pg_toupper and pg_tolower. These functions use the same notions of case folding already developed for identifier case conversion. I left the straight locale-based folding in place for situations where we are just manipulating user data and not trying to match it to built-in strings --- for example, the SQL upper() function is still locale dependent. Perhaps this will prove not to be what's wanted, but at the moment we can initdb and pass regression tests in Turkish locale.
2004-05-07 02:24:59 +02:00
else if (pg_strncasecmp(num, "-Infinity", 9) == 0)
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
val = -get_float8_infinity();
Portability fixes and bug fixes for recent floating point input changes. In particular, don't depend on strtod() to accept 'NaN' and 'Infinity' inputs (while this is required by C99, not all platforms are compliant with that yet). Also, don't require glibc's behavior from isinf(): it seems that on a lot of platforms isinf() does not itself distinguish between negative and positive infinity.
2004-03-14 06:22:52 +01:00
endptr = num + 9;
}
Make sure float4in/float8in accept all standard spellings of "infinity". The C99 and POSIX standards require strtod() to accept all these spellings (case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity", "-infinity". However, pre-C99 systems might accept only some or none of these, and apparently Windows still doesn't accept "inf". To avoid surprising cross-platform behavioral differences, manually check for each of these spellings if strtod() fails. We were previously handling just "infinity" and "-infinity" that way, but since C99 is most of the world now, it seems likely that applications are expecting all these spellings to work. Per bug #8355 from Basil Peace. It turns out this fix won't actually resolve his problem, because Python isn't being this careful; but that doesn't mean we shouldn't be.
2013-08-03 18:39:47 +02:00
else if (pg_strncasecmp(num, "inf", 3) == 0)
{
val = get_float8_infinity();
endptr = num + 3;
}
else if (pg_strncasecmp(num, "+inf", 4) == 0)
{
val = get_float8_infinity();
endptr = num + 4;
}
else if (pg_strncasecmp(num, "-inf", 4) == 0)
{
val = -get_float8_infinity();
endptr = num + 4;
}
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
else if (save_errno == ERANGE)
{
/*
* Some platforms return ERANGE for denormalized numbers (those
* that are not zero, but are too close to zero to have full
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* precision). We'd prefer not to throw error for that, so try to
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* detect whether it's a "real" out-of-range condition by checking
* to see if the result is zero or huge.
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
*
* On error, we intentionally complain about double precision not
* the given type name, and we print only the part of the string
* that is the current number.
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
*/
if (val == 0.0 || val >= HUGE_VAL || val <= -HUGE_VAL)
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
{
char *errnumber = pstrdup(num);
errnumber[endptr - num] = '\0';
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
RETURN_ERROR(ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
Add safeguards in LSN, numeric and float calculation for custom errors Those data types use parsing and/or calculation wrapper routines which can generate some generic error messages in the event of a failure. The caller of these routines can also pass a pointer variable settable by the routine to track if an error has happened, letting the caller decide what to do in the event of an error and what error message to generate. Those routines have been slacking the initialization of the tracking flag, which can be confusing when reading the code, so add some safeguards against calls of these parsing routines which could lead to a dubious result. The LSN parsing gains an assertion to make sure that the tracking flag is set, while numeric and float paths initialize the flag to a saner state. Author: Jeevan Ladhe Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com
2019-08-05 08:35:16 +02:00
errmsg("\"%s\" is out of range for type double precision",
errnumber))),
have_error);
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
}
Try to be more consistent about accepting denormalized float8 numbers. On some platforms, strtod() reports ERANGE for a denormalized value (ie, one that can be represented as distinct from zero, but is too small to have full precision). On others, it doesn't. It seems better to try to accept these values consistently, so add a test to see if the result value indicates a true out-of-range condition. This should be okay per Single Unix Spec. On machines where the underlying math isn't IEEE standard, the behavior for such small numbers may not be very consistent, but then it wouldn't be anyway. Marti Raudsepp, after a proposal by Jeroen Vermeulen
2012-02-01 19:11:16 +01:00
}
Handle "NaN" and "Infinity" for input values. I think NAN is already guaranteed to be there from Jan's work on NUMERIC, but perhaps HUGE_VAL needs some #ifndef's in the same place. Should also include "-Infinity" as -HUGE_VAL sometime; not there yet.
1999-01-10 18:13:06 +01:00
else
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
RETURN_ERROR(ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("invalid input syntax for type "
"%s: \"%s\"",
Add safeguards in LSN, numeric and float calculation for custom errors Those data types use parsing and/or calculation wrapper routines which can generate some generic error messages in the event of a failure. The caller of these routines can also pass a pointer variable settable by the routine to track if an error has happened, letting the caller decide what to do in the event of an error and what error message to generate. Those routines have been slacking the initialization of the tracking flag, which can be confusing when reading the code, so add some safeguards against calls of these parsing routines which could lead to a dubious result. The LSN parsing gains an assertion to make sure that the tracking flag is set, while numeric and float paths initialize the flag to a saner state. Author: Jeevan Ladhe Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com
2019-08-05 08:35:16 +02:00
type_name, orig_string))),
have_error);
Handle "NaN" and "Infinity" for input values. I think NAN is already guaranteed to be there from Jan's work on NUMERIC, but perhaps HUGE_VAL needs some #ifndef's in the same place. Should also include "-Infinity" as -HUGE_VAL sometime; not there yet.
1999-01-10 18:13:06 +01:00
}
Work around broken strtod() that's present in many Solaris releases. Thanks to Michael Fuhr for identifying the problem.
2004-08-11 19:20:50 +02:00
#ifdef HAVE_BUGGY_SOLARIS_STRTOD
else
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Many versions of Solaris have a bug wherein strtod sets endptr to
* point one byte beyond the end of the string when given "inf" or
* "infinity".
Work around broken strtod() that's present in many Solaris releases. Thanks to Michael Fuhr for identifying the problem.
2004-08-11 19:20:50 +02:00
*/
if (endptr != num && endptr[-1] == '\0')
endptr--;
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* HAVE_BUGGY_SOLARIS_STRTOD */
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
/* skip trailing whitespace */
Add missing casts to unsigned char in recently-added isspace() calls.
2004-04-02 00:51:31 +02:00
while (*endptr != '\0' && isspace((unsigned char) *endptr))
Revise int2/int4/int8/float4/float8 input routines to allow for any amount of leading or trailing whitespace (where "whitespace" is defined by isspace()). This is for SQL conformance, as well as consistency with other numeric types (e.g. oid, numeric). Also refactor pg_atoi() to avoid looking at errno where not necessary, and add a bunch of regression tests for the input to these types.
2004-03-11 03:11:14 +01:00
endptr++;
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
/* report stopping point if wanted, else complain if not end of string */
if (endptr_p)
*endptr_p = endptr;
else if (*endptr != '\0')
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
RETURN_ERROR(ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("invalid input syntax for type "
"%s: \"%s\"",
Add safeguards in LSN, numeric and float calculation for custom errors Those data types use parsing and/or calculation wrapper routines which can generate some generic error messages in the event of a failure. The caller of these routines can also pass a pointer variable settable by the routine to track if an error has happened, letting the caller decide what to do in the event of an error and what error message to generate. Those routines have been slacking the initialization of the tracking flag, which can be confusing when reading the code, so add some safeguards against calls of these parsing routines which could lead to a dubious result. The LSN parsing gains an assertion to make sure that the tracking flag is set, while numeric and float paths initialize the flag to a saner state. Author: Jeevan Ladhe Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com
2019-08-05 08:35:16 +02:00
type_name, orig_string))),
have_error);
Emit a warning when an empty string is input to the oid, float4, and float8 types. This begins the deprecation of this feature: in 7.6, this input will be rejected. Also added a new error code for warnings about deprecated features, and updated the regression tests.
2004-03-04 22:47:18 +01:00
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
return val;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
/*
Fix typos. Reported-by: Alexander Lakhin Author: Alexander Lakhin Reviewed-by: Amit Kapila and Tom Lane Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com
2019-05-26 14:58:18 +02:00
* Interface to float8in_internal_opt_error() without "have_error" argument.
Numeric error suppression in jsonpath Add support of numeric error suppression to jsonpath as it's required by standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement that. Instead, it provides internal versions of numeric functions used, which support error suppression. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Alexander Korotkov, Nikita Glukhov Reviewed-by: Tomas Vondra
2019-03-16 10:21:19 +01:00
*/
double
float8in_internal(char *num, char **endptr_p,
const char *type_name, const char *orig_string)
{
return float8in_internal_opt_error(num, endptr_p, type_name,
orig_string, NULL);
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* float8out - converts float8 number to a string
* using a standard output format
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8out(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 num = PG_GETARG_FLOAT8(0);
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
PG_RETURN_CSTRING(float8out_internal(num));
}
/*
* float8out_internal - guts of float8out()
*
* This is exposed for use by functions that want a reasonably
* platform-independent way of outputting doubles.
* The result is always palloc'd.
*/
char *
float8out_internal(double num)
{
Improve snprintf.c's handling of NaN, Infinity, and minus zero. Up to now, float4out/float8out handled NaN and Infinity cases explicitly, and invoked psprintf only for ordinary float values. This was done because platform implementations of snprintf produce varying representations of these special cases. But now that we use snprintf.c always, it's better to give it the responsibility to produce a uniform representation of these cases, so that we have uniformity across the board not only in float4out/float8out. Hence, move that work into fmtfloat(). Also, teach fmtfloat() to recognize IEEE minus zero and handle it correctly. The previous coding worked only accidentally, and would fail for e.g. "%+f" format (it'd print "+-0.00000"). Now that we're using snprintf.c everywhere, it's not acceptable for it to do weird things in corner cases. (This incidentally avoids a portability problem we've seen on some really ancient platforms, that native sprintf does the wrong thing with minus zero.) Also, introduce a new entry point in snprintf.c to allow float[48]out to bypass the work of interpreting a well-known format spec, as well as bypassing the overhead of the psprintf layer. I modeled this API loosely on strfromd(). In my testing, this brings float[48]out back to approximately the same speed they had when using native snprintf, fixing one of the main performance issues caused by using snprintf.c. (There is some talk of more aggressive work to improve the speed of floating-point output conversion, but these changes seem to provide a better starting point for such work anyway.) Getting rid of the previous ad-hoc hack for Infinity/NaN in fmtfloat() allows removing <ctype.h> from snprintf.c's #includes. I also removed a few other #includes that I think are historical, though the buildfarm may expose that as wrong. Discussion: https://postgr.es/m/13178.1538794717@sss.pgh.pa.us
2018-10-08 18:19:20 +02:00
char *ascii = (char *) palloc(32);
int ndig = DBL_DIG + extra_float_digits;
Add extra_float_digits GUC parameter to allow adjustment of displayed precision for float4, float8, and geometric types. Set it in pg_dump so that float data can be dumped/reloaded exactly (at least on platforms where the float I/O support is properly implemented). Initial patch by Pedro Ferreira, some additional work by Tom Lane.
2002-11-08 18:37:52 +01:00
Change floating-point output format for improved performance. Previously, floating-point output was done by rounding to a specific decimal precision; by default, to 6 or 15 decimal digits (losing information) or as requested using extra_float_digits. Drivers that wanted exact float values, and applications like pg_dump that must preserve values exactly, set extra_float_digits=3 (or sometimes 2 for historical reasons, though this isn't enough for float4). Unfortunately, decimal rounded output is slow enough to become a noticable bottleneck when dealing with large result sets or COPY of large tables when many floating-point values are involved. Floating-point output can be done much faster when the output is not rounded to a specific decimal length, but rather is chosen as the shortest decimal representation that is closer to the original float value than to any other value representable in the same precision. The recently published Ryu algorithm by Ulf Adams is both relatively simple and remarkably fast. Accordingly, change float4out/float8out to output shortest decimal representations if extra_float_digits is greater than 0, and make that the new default. Applications that need rounded output can set extra_float_digits back to 0 or below, and take the resulting performance hit. We make one concession to portability for systems with buggy floating-point input: we do not output decimal values that fall exactly halfway between adjacent representable binary values (which would rely on the reader doing round-to-nearest-even correctly). This is known to be a problem at least for VS2013 on Windows. Our version of the Ryu code originates from https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the following (significant) modifications: - Output format is changed to use fixed-point notation for small exponents, as printf would, and also to use lowercase 'e', a minimum of 2 exponent digits, and a mandatory sign on the exponent, to keep the formatting as close as possible to previous output. - The output of exact midpoint values is disabled as noted above. - The integer fast-path code is changed somewhat (since we have fixed-point output and the upstream did not). - Our project style has been largely applied to the code with the exception of C99 declaration-after-statement, which has been retained as an exception to our present policy. - Most of upstream's debugging and conditionals are removed, and we use our own configure tests to determine things like uint128 availability. Changing the float output format obviously affects a number of regression tests. This patch uses an explicit setting of extra_float_digits=0 for test output that is not expected to be exactly reproducible (e.g. due to numerical instability or differing algorithms for transcendental functions). Conversions from floats to numeric are unchanged by this patch. These may appear in index expressions and it is not yet clear whether any change should be made, so that can be left for another day. This patch assumes that the only supported floating point format is now IEEE format, and the documentation is updated to reflect that. Code by me, adapting the work of Ulf Adams and other contributors. References: https://dl.acm.org/citation.cfm?id=3192369 Reviewed-by: Tom Lane, Andres Freund, Donald Dong Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
if (extra_float_digits > 0)
{
double_to_shortest_decimal_buf(num, ascii);
return ascii;
}
Improve snprintf.c's handling of NaN, Infinity, and minus zero. Up to now, float4out/float8out handled NaN and Infinity cases explicitly, and invoked psprintf only for ordinary float values. This was done because platform implementations of snprintf produce varying representations of these special cases. But now that we use snprintf.c always, it's better to give it the responsibility to produce a uniform representation of these cases, so that we have uniformity across the board not only in float4out/float8out. Hence, move that work into fmtfloat(). Also, teach fmtfloat() to recognize IEEE minus zero and handle it correctly. The previous coding worked only accidentally, and would fail for e.g. "%+f" format (it'd print "+-0.00000"). Now that we're using snprintf.c everywhere, it's not acceptable for it to do weird things in corner cases. (This incidentally avoids a portability problem we've seen on some really ancient platforms, that native sprintf does the wrong thing with minus zero.) Also, introduce a new entry point in snprintf.c to allow float[48]out to bypass the work of interpreting a well-known format spec, as well as bypassing the overhead of the psprintf layer. I modeled this API loosely on strfromd(). In my testing, this brings float[48]out back to approximately the same speed they had when using native snprintf, fixing one of the main performance issues caused by using snprintf.c. (There is some talk of more aggressive work to improve the speed of floating-point output conversion, but these changes seem to provide a better starting point for such work anyway.) Getting rid of the previous ad-hoc hack for Infinity/NaN in fmtfloat() allows removing <ctype.h> from snprintf.c's #includes. I also removed a few other #includes that I think are historical, though the buildfarm may expose that as wrong. Discussion: https://postgr.es/m/13178.1538794717@sss.pgh.pa.us
2018-10-08 18:19:20 +02:00
(void) pg_strfromd(ascii, 32, ndig, num);
Improve portability of I/O behavior for the geometric types. Formerly, the geometric I/O routines such as box_in and point_out relied directly on strtod() and sprintf() for conversion of the float8 component values of their data types. However, the behavior of those functions is pretty platform-dependent, especially for edge-case values such as infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which added test cases involving boxes with infinity endpoints, and immediately failed on Windows and AIX buildfarm members. We solved these problems years ago in the main float8in and float8out functions, so let's fix it by making the geometric types use that code instead of depending directly on the platform-supplied functions. To do this, refactor the float8in code so that it can be used to parse just part of a string, and as a convenience make the guts of float8out usable without going through DirectFunctionCall. While at it, get rid of geo_ops.c's fairly shaky assumptions about the maximum output string length for a double, by having it build results in StringInfo buffers instead of fixed-length strings. In passing, convert all the "invalid input syntax for type foo" messages in this area of the code into "invalid input syntax for type %s" to reduce the number of distinct translatable strings, per recent discussion. We would have needed a fair number of the latter anyway for code-sharing reasons, so we might as well just go whole hog. Note: this patch is by no means intended to guarantee that the geometric types uniformly behave sanely for infinity or NaN component values. But any bugs we have in that line were there all along, they were just harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
return ascii;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
COPY BINARY uses the new binary I/O routines. Update a few more datatypes so that COPY BINARY regression test passes.
2003-05-09 23:19:50 +02:00
/*
* float8recv - converts external binary format to float8
*/
Datum
float8recv(PG_FUNCTION_ARGS)
{
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
PG_RETURN_FLOAT8(pq_getmsgfloat8(buf));
}
/*
* float8send - converts float8 to binary format
*/
Datum
float8send(PG_FUNCTION_ARGS)
{
float8 num = PG_GETARG_FLOAT8(0);
StringInfoData buf;
pq_begintypsend(&buf);
pq_sendfloat8(&buf, num);
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/* ========== PUBLIC ROUTINES ========== */
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ======================
* FLOAT4 BASE OPERATIONS
* ======================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float4abs - returns |arg1| (absolute value)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4abs(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT4((float4) fabs(arg1));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float4um - returns -arg1 (unary minus)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4um(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
float4 result;
Remove the special cases to prevent minus-zero results in float4 and float8 unary minus operators. We weren't attempting to prevent minus zero anywhere else; in view of our gradual trend to make the float datatypes more IEEE standard compliant, we should allow minus zero here rather than disallow it elsewhere. We don't, however, expect that all platforms will produce minus zero, so we need to adjust the one affected regression test to allow both results. Per discussion of bug #4660. (In passing, clean up a couple other minor infelicities in float.c.)
2009-02-18 20:23:26 +01:00
result = -arg1;
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT4(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
This adds unary plus capability. No grammar changes, per Tom's request. Marko Kreen
2001-06-07 02:09:32 +02:00
Datum
float4up(PG_FUNCTION_ARGS)
{
float4 arg = PG_GETARG_FLOAT4(0);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
This adds unary plus capability. No grammar changes, per Tom's request. Marko Kreen
2001-06-07 02:09:32 +02:00
PG_RETURN_FLOAT4(arg);
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4larger(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
float4 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
if (float4_gt(arg1, arg2))
Fix numeric_smaller, numeric_larger, float4smaller, float4larger, float8smaller, float8larger (and thereby the MIN/MAX aggregates on these datatypes) to agree with the datatypes' comparison operations as regards NaN handling. In all these datatypes, NaN is arbitrarily considered larger than any normal value ... but MIN/MAX had not gotten the word. Per recent discussion on pgsql-sql.
2003-07-30 21:48:41 +02:00
result = arg1;
else
result = arg2;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT4(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4smaller(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
float4 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
if (float4_lt(arg1, arg2))
Fix numeric_smaller, numeric_larger, float4smaller, float4larger, float8smaller, float8larger (and thereby the MIN/MAX aggregates on these datatypes) to agree with the datatypes' comparison operations as regards NaN handling. In all these datatypes, NaN is arbitrarily considered larger than any normal value ... but MIN/MAX had not gotten the word. Per recent discussion on pgsql-sql.
2003-07-30 21:48:41 +02:00
result = arg1;
else
result = arg2;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT4(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ======================
* FLOAT8 BASE OPERATIONS
* ======================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float8abs - returns |arg1| (absolute value)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8abs(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT8(fabs(arg1));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float8um - returns -arg1 (unary minus)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8um(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Remove the special cases to prevent minus-zero results in float4 and float8 unary minus operators. We weren't attempting to prevent minus zero anywhere else; in view of our gradual trend to make the float datatypes more IEEE standard compliant, we should allow minus zero here rather than disallow it elsewhere. We don't, however, expect that all platforms will produce minus zero, so we need to adjust the one affected regression test to allow both results. Per discussion of bug #4660. (In passing, clean up a couple other minor infelicities in float.c.)
2009-02-18 20:23:26 +01:00
result = -arg1;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
This adds unary plus capability. No grammar changes, per Tom's request. Marko Kreen
2001-06-07 02:09:32 +02:00
Datum
float8up(PG_FUNCTION_ARGS)
{
float8 arg = PG_GETARG_FLOAT8(0);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
This adds unary plus capability. No grammar changes, per Tom's request. Marko Kreen
2001-06-07 02:09:32 +02:00
PG_RETURN_FLOAT8(arg);
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8larger(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
if (float8_gt(arg1, arg2))
Fix numeric_smaller, numeric_larger, float4smaller, float4larger, float8smaller, float8larger (and thereby the MIN/MAX aggregates on these datatypes) to agree with the datatypes' comparison operations as regards NaN handling. In all these datatypes, NaN is arbitrarily considered larger than any normal value ... but MIN/MAX had not gotten the word. Per recent discussion on pgsql-sql.
2003-07-30 21:48:41 +02:00
result = arg1;
else
result = arg2;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8smaller(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
if (float8_lt(arg1, arg2))
Fix numeric_smaller, numeric_larger, float4smaller, float4larger, float8smaller, float8larger (and thereby the MIN/MAX aggregates on these datatypes) to agree with the datatypes' comparison operations as regards NaN handling. In all these datatypes, NaN is arbitrarily considered larger than any normal value ... but MIN/MAX had not gotten the word. Per recent discussion on pgsql-sql.
2003-07-30 21:48:41 +02:00
result = arg1;
else
result = arg2;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ====================
* ARITHMETIC OPERATORS
* ====================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float4pl - returns arg1 + arg2
* float4mi - returns arg1 - arg2
* float4mul - returns arg1 * arg2
* float4div - returns arg1 / arg2
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4pl(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Remove the special cases to prevent minus-zero results in float4 and float8 unary minus operators. We weren't attempting to prevent minus zero anywhere else; in view of our gradual trend to make the float datatypes more IEEE standard compliant, we should allow minus zero here rather than disallow it elsewhere. We don't, however, expect that all platforms will produce minus zero, so we need to adjust the one affected regression test to allow both results. Per discussion of bug #4660. (In passing, clean up a couple other minor infelicities in float.c.)
2009-02-18 20:23:26 +01:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT4(float4_pl(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4mi(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT4(float4_mi(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4mul(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT4(float4_mul(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4div(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT4(float4_div(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float8pl - returns arg1 + arg2
* float8mi - returns arg1 - arg2
* float8mul - returns arg1 * arg2
* float8div - returns arg1 / arg2
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8pl(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_pl(arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8mi(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mi(arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8mul(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mul(arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8div(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_div(arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ====================
* COMPARISON OPERATORS
* ====================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* float4{eq,ne,lt,le,gt,ge} - float4/float4 comparison operations
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Fix GiST index build for NaN values in geometric types. GiST index build could go into an infinite loop when presented with boxes (or points, circles or polygons) containing NaN component values. This happened essentially because the code assumed that x == x is true for any "double" value x; but it's not true for NaNs. The looping behavior was not the only problem though: we also attempted to sort the items using simple double comparisons. Since NaNs violate the trichotomy law, qsort could (in principle at least) get arbitrarily confused and mess up the sorting of ordinary values as well as NaNs. And we based splitting choices on box size calculations that could produce NaNs, again resulting in undesirable behavior. To fix, replace all comparisons of doubles in this logic with float8_cmp_internal, which is NaN-aware and is careful to sort NaNs consistently, higher than any non-NaN. Also rearrange the box size calculation to not produce NaNs; instead it should produce an infinity for a box with NaN on one side and not-NaN on the other. I don't by any means claim that this solves all problems with NaNs in geometric values, but it should at least make GiST index insertion work reliably with such data. It's likely that the index search side of things still needs some work, and probably regular geometric operations too. But with this patch we're laying down a convention for how such cases ought to behave. Per bug #14238 from Guang-Dih Lei. Back-patch to 9.2; the code used before commit 7f3bd86843e5aad8 is quite different and doesn't lock up on my simple test case, nor on the submitter's dataset. Report: <20160708151747.1426.60150@wrigleys.postgresql.org> Discussion: <28685.1468246504@sss.pgh.pa.us>
2016-07-15 00:45:59 +02:00
int
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
float4_cmp_internal(float4 a, float4 b)
{
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
if (float4_gt(a, b))
return 1;
if (float4_lt(a, b))
return -1;
return 0;
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4eq(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float4_eq(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4ne(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float4_ne(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4lt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float4_lt(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4le(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float4_le(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4gt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float4_gt(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float4ge(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float4_ge(arg1, arg2));
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
}
Datum
btfloat4cmp(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
PG_RETURN_INT32(float4_cmp_internal(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Create a "sort support" interface API for faster sorting. This patch creates an API whereby a btree index opclass can optionally provide non-SQL-callable support functions for sorting. In the initial patch, we only use this to provide a directly-callable comparator function, which can be invoked with a bit less overhead than the traditional SQL-callable comparator. While that should be of value in itself, the real reason for doing this is to provide a datatype-extensible framework for more aggressive optimizations, as in Peter Geoghegan's recent work. Robert Haas and Tom Lane
2011-12-07 06:18:38 +01:00
static int
btfloat4fastcmp(Datum x, Datum y, SortSupport ssup)
{
float4 arg1 = DatumGetFloat4(x);
float4 arg2 = DatumGetFloat4(y);
return float4_cmp_internal(arg1, arg2);
}
Datum
btfloat4sortsupport(PG_FUNCTION_ARGS)
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
Create a "sort support" interface API for faster sorting. This patch creates an API whereby a btree index opclass can optionally provide non-SQL-callable support functions for sorting. In the initial patch, we only use this to provide a directly-callable comparator function, which can be invoked with a bit less overhead than the traditional SQL-callable comparator. While that should be of value in itself, the real reason for doing this is to provide a datatype-extensible framework for more aggressive optimizations, as in Peter Geoghegan's recent work. Robert Haas and Tom Lane
2011-12-07 06:18:38 +01:00
ssup->comparator = btfloat4fastcmp;
PG_RETURN_VOID();
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* float8{eq,ne,lt,le,gt,ge} - float8/float8 comparison operations
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Fix GiST index build for NaN values in geometric types. GiST index build could go into an infinite loop when presented with boxes (or points, circles or polygons) containing NaN component values. This happened essentially because the code assumed that x == x is true for any "double" value x; but it's not true for NaNs. The looping behavior was not the only problem though: we also attempted to sort the items using simple double comparisons. Since NaNs violate the trichotomy law, qsort could (in principle at least) get arbitrarily confused and mess up the sorting of ordinary values as well as NaNs. And we based splitting choices on box size calculations that could produce NaNs, again resulting in undesirable behavior. To fix, replace all comparisons of doubles in this logic with float8_cmp_internal, which is NaN-aware and is careful to sort NaNs consistently, higher than any non-NaN. Also rearrange the box size calculation to not produce NaNs; instead it should produce an infinity for a box with NaN on one side and not-NaN on the other. I don't by any means claim that this solves all problems with NaNs in geometric values, but it should at least make GiST index insertion work reliably with such data. It's likely that the index search side of things still needs some work, and probably regular geometric operations too. But with this patch we're laying down a convention for how such cases ought to behave. Per bug #14238 from Guang-Dih Lei. Back-patch to 9.2; the code used before commit 7f3bd86843e5aad8 is quite different and doesn't lock up on my simple test case, nor on the submitter's dataset. Report: <20160708151747.1426.60150@wrigleys.postgresql.org> Discussion: <28685.1468246504@sss.pgh.pa.us>
2016-07-15 00:45:59 +02:00
int
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
float8_cmp_internal(float8 a, float8 b)
{
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
if (float8_gt(a, b))
return 1;
if (float8_lt(a, b))
return -1;
return 0;
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8eq(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_eq(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8ne(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_ne(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8lt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_lt(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8le(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_le(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8gt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_gt(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float8ge(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_ge(arg1, arg2));
Ensure that btree sort ordering functions and boolean comparison operators give consistent results for all datatypes. Types float4, float8, and numeric were broken for NaN values; abstime, timestamp, and interval were broken for INVALID values; timetz was just plain broken (some possible pairs of values were neither < nor = nor >). Also clean up text, bpchar, varchar, and bit/varbit to eliminate duplicate code and thereby reduce the probability of similar inconsistencies arising in the future.
2001-05-03 21:00:37 +02:00
}
Datum
btfloat8cmp(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
PG_RETURN_INT32(float8_cmp_internal(arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Create a "sort support" interface API for faster sorting. This patch creates an API whereby a btree index opclass can optionally provide non-SQL-callable support functions for sorting. In the initial patch, we only use this to provide a directly-callable comparator function, which can be invoked with a bit less overhead than the traditional SQL-callable comparator. While that should be of value in itself, the real reason for doing this is to provide a datatype-extensible framework for more aggressive optimizations, as in Peter Geoghegan's recent work. Robert Haas and Tom Lane
2011-12-07 06:18:38 +01:00
static int
btfloat8fastcmp(Datum x, Datum y, SortSupport ssup)
{
float8 arg1 = DatumGetFloat8(x);
float8 arg2 = DatumGetFloat8(y);
return float8_cmp_internal(arg1, arg2);
}
Datum
btfloat8sortsupport(PG_FUNCTION_ARGS)
{
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
Create a "sort support" interface API for faster sorting. This patch creates an API whereby a btree index opclass can optionally provide non-SQL-callable support functions for sorting. In the initial patch, we only use this to provide a directly-callable comparator function, which can be invoked with a bit less overhead than the traditional SQL-callable comparator. While that should be of value in itself, the real reason for doing this is to provide a datatype-extensible framework for more aggressive optimizations, as in Peter Geoghegan's recent work. Robert Haas and Tom Lane
2011-12-07 06:18:38 +01:00
ssup->comparator = btfloat8fastcmp;
PG_RETURN_VOID();
}
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
Datum
btfloat48cmp(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
/* widen float4 to float8 and then compare */
PG_RETURN_INT32(float8_cmp_internal(arg1, arg2));
}
Datum
btfloat84cmp(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
/* widen float4 to float8 and then compare */
PG_RETURN_INT32(float8_cmp_internal(arg1, arg2));
}
Add window RANGE support for float4, float8, numeric. Commit 0a459cec9 left this for later, but since time's running out, I went ahead and took care of it. There are more data types that somebody might someday want RANGE support for, but this is enough to satisfy all expectations of the SQL standard, which just says that "numeric, datetime, and interval" types should have RANGE support.
2018-02-24 19:23:38 +01:00
/*
* in_range support function for float8.
*
* Note: we needn't supply a float8_float4 variant, as implicit coercion
* of the offset value takes care of that scenario just as well.
*/
Datum
in_range_float8_float8(PG_FUNCTION_ARGS)
{
float8 val = PG_GETARG_FLOAT8(0);
float8 base = PG_GETARG_FLOAT8(1);
float8 offset = PG_GETARG_FLOAT8(2);
bool sub = PG_GETARG_BOOL(3);
bool less = PG_GETARG_BOOL(4);
float8 sum;
/*
* Reject negative or NaN offset. Negative is per spec, and NaN is
* because appropriate semantics for that seem non-obvious.
*/
if (isnan(offset) || offset < 0)
ereport(ERROR,
Make new error code name match SQL standard more closely Discussion: https://www.postgresql.org/message-id/dff3d555-bea4-ac24-29b2-29521b9d08e8%402ndquadrant.com
2018-06-11 17:15:28 +02:00
(errcode(ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE),
Add window RANGE support for float4, float8, numeric. Commit 0a459cec9 left this for later, but since time's running out, I went ahead and took care of it. There are more data types that somebody might someday want RANGE support for, but this is enough to satisfy all expectations of the SQL standard, which just says that "numeric, datetime, and interval" types should have RANGE support.
2018-02-24 19:23:38 +01:00
errmsg("invalid preceding or following size in window function")));
/*
* Deal with cases where val and/or base is NaN, following the rule that
* NaN sorts after non-NaN (cf float8_cmp_internal). The offset cannot
* affect the conclusion.
*/
if (isnan(val))
{
if (isnan(base))
PG_RETURN_BOOL(true); /* NAN = NAN */
else
PG_RETURN_BOOL(!less); /* NAN > non-NAN */
}
else if (isnan(base))
{
PG_RETURN_BOOL(less); /* non-NAN < NAN */
}
/*
* Deal with infinite offset (necessarily +inf, at this point). We must
* special-case this because if base happens to be -inf, their sum would
* be NaN, which is an overflow-ish condition we should avoid.
*/
if (isinf(offset))
{
PG_RETURN_BOOL(sub ? !less : less);
}
/*
* Otherwise it should be safe to compute base +/- offset. We trust the
* FPU to cope if base is +/-inf or the true sum would overflow, and
* produce a suitably signed infinity, which will compare properly against
* val whether or not that's infinity.
*/
if (sub)
sum = base - offset;
else
sum = base + offset;
if (less)
PG_RETURN_BOOL(val <= sum);
else
PG_RETURN_BOOL(val >= sum);
}
/*
* in_range support function for float4.
*
* We would need a float4_float8 variant in any case, so we supply that and
* let implicit coercion take care of the float4_float4 case.
*/
Datum
in_range_float4_float8(PG_FUNCTION_ARGS)
{
Put in_range_float4_float8's work in-line. In commit 8b29e88cd, I'd dithered about whether to make in_range_float4_float8 be a standalone copy of the float in-range logic or have it punt to in_range_float8_float8. I went with the latter, which saves code space though at the cost of performance and readability. However, it emerges that this tickles a compiler or hardware bug on buildfarm member opossum. Test results from commit 55e0e4581 show conclusively that widening a float4 NaN to float8 produces Inf, not NaN, on that machine; which accounts perfectly for the window RANGE test failures it's been showing. We can dodge this problem by making in_range_float4_float8 be an independent function, so that it checks for NaN inputs before widening them. Ordinarily I'd not be very excited about working around such obviously broken functionality; but given that this was a judgment call to begin with, I don't mind reversing it.
2018-05-05 19:21:50 +02:00
float4 val = PG_GETARG_FLOAT4(0);
float4 base = PG_GETARG_FLOAT4(1);
float8 offset = PG_GETARG_FLOAT8(2);
bool sub = PG_GETARG_BOOL(3);
bool less = PG_GETARG_BOOL(4);
float8 sum;
/*
* Reject negative or NaN offset. Negative is per spec, and NaN is
* because appropriate semantics for that seem non-obvious.
*/
if (isnan(offset) || offset < 0)
ereport(ERROR,
Make new error code name match SQL standard more closely Discussion: https://www.postgresql.org/message-id/dff3d555-bea4-ac24-29b2-29521b9d08e8%402ndquadrant.com
2018-06-11 17:15:28 +02:00
(errcode(ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE),
Put in_range_float4_float8's work in-line. In commit 8b29e88cd, I'd dithered about whether to make in_range_float4_float8 be a standalone copy of the float in-range logic or have it punt to in_range_float8_float8. I went with the latter, which saves code space though at the cost of performance and readability. However, it emerges that this tickles a compiler or hardware bug on buildfarm member opossum. Test results from commit 55e0e4581 show conclusively that widening a float4 NaN to float8 produces Inf, not NaN, on that machine; which accounts perfectly for the window RANGE test failures it's been showing. We can dodge this problem by making in_range_float4_float8 be an independent function, so that it checks for NaN inputs before widening them. Ordinarily I'd not be very excited about working around such obviously broken functionality; but given that this was a judgment call to begin with, I don't mind reversing it.
2018-05-05 19:21:50 +02:00
errmsg("invalid preceding or following size in window function")));
/*
* Deal with cases where val and/or base is NaN, following the rule that
* NaN sorts after non-NaN (cf float8_cmp_internal). The offset cannot
* affect the conclusion.
*/
if (isnan(val))
{
if (isnan(base))
PG_RETURN_BOOL(true); /* NAN = NAN */
else
PG_RETURN_BOOL(!less); /* NAN > non-NAN */
}
else if (isnan(base))
{
PG_RETURN_BOOL(less); /* non-NAN < NAN */
}
/*
* Deal with infinite offset (necessarily +inf, at this point). We must
* special-case this because if base happens to be -inf, their sum would
* be NaN, which is an overflow-ish condition we should avoid.
*/
if (isinf(offset))
{
PG_RETURN_BOOL(sub ? !less : less);
}
/*
* Otherwise it should be safe to compute base +/- offset. We trust the
* FPU to cope if base is +/-inf or the true sum would overflow, and
* produce a suitably signed infinity, which will compare properly against
* val whether or not that's infinity.
*/
if (sub)
sum = base - offset;
else
sum = base + offset;
if (less)
PG_RETURN_BOOL(val <= sum);
else
PG_RETURN_BOOL(val >= sum);
Add window RANGE support for float4, float8, numeric. Commit 0a459cec9 left this for later, but since time's running out, I went ahead and took care of it. There are more data types that somebody might someday want RANGE support for, but this is enough to satisfy all expectations of the SQL standard, which just says that "numeric, datetime, and interval" types should have RANGE support.
2018-02-24 19:23:38 +01:00
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ===================
* CONVERSION ROUTINES
* ===================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ftod - converts a float4 number to a float8 number
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
ftod(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 num = PG_GETARG_FLOAT4(0);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8((float8) num);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* dtof - converts a float8 number to a float4 number
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dtof(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 num = PG_GETARG_FLOAT8(0);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float4_val((float4) num, isinf(num), num == 0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT4((float4) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* dtoi4 - converts a float8 number to an int4 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dtoi4(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 num = PG_GETARG_FLOAT8(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
/*
* Get rid of any fractional part in the input. This is so we don't fail
* on just-out-of-range values that would round into range. Note
* assumption that rint() will pass through a NaN or Inf unchanged.
*/
num = rint(num);
Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-int64 logic had the same sorts of edge-case problems that cbdb8b4c0 fixed in the core code. To make this easier to get right in future, put the guts of the checks into new macros in c.h, and add commentary about how to use the macros correctly. Back-patch to all supported branches, as we did with the previous fix. Yuya Watari Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com
2019-11-07 17:22:52 +01:00
/* Range check */
if (unlikely(isnan(num) || !FLOAT8_FITS_IN_INT32(num)))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("integer out of range")));
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
PG_RETURN_INT32((int32) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* dtoi2 - converts a float8 number to an int2 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
Datum
dtoi2(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
float8 num = PG_GETARG_FLOAT8(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
/*
* Get rid of any fractional part in the input. This is so we don't fail
* on just-out-of-range values that would round into range. Note
* assumption that rint() will pass through a NaN or Inf unchanged.
*/
num = rint(num);
Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-int64 logic had the same sorts of edge-case problems that cbdb8b4c0 fixed in the core code. To make this easier to get right in future, put the guts of the checks into new macros in c.h, and add commentary about how to use the macros correctly. Back-patch to all supported branches, as we did with the previous fix. Yuya Watari Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com
2019-11-07 17:22:52 +01:00
/* Range check */
if (unlikely(isnan(num) || !FLOAT8_FITS_IN_INT16(num)))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
Detect overflow in integer arithmetic operators (integer, smallint, and bigint variants). Clean up some inconsistencies in error message wording. Fix scanint8 to allow trailing whitespace in INT64_MIN case. Update int8-exp-three-digits.out, which seems to have been ignored by the last couple of people to modify the int8 regression test, and remove int8-exp-three-digits-win32.out which is thereby exposed as redundant.
2004-10-04 16:42:48 +02:00
errmsg("smallint out of range")));
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
PG_RETURN_INT16((int16) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* i4tod - converts an int4 number to a float8 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
Datum
i4tod(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
int32 num = PG_GETARG_INT32(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT8((float8) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* i2tod - converts an int2 number to a float8 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
Datum
i2tod(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
int16 num = PG_GETARG_INT16(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT8((float8) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* ftoi4 - converts a float4 number to an int4 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
ftoi4(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 num = PG_GETARG_FLOAT4(0);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
/*
* Get rid of any fractional part in the input. This is so we don't fail
* on just-out-of-range values that would round into range. Note
* assumption that rint() will pass through a NaN or Inf unchanged.
*/
num = rint(num);
Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-int64 logic had the same sorts of edge-case problems that cbdb8b4c0 fixed in the core code. To make this easier to get right in future, put the guts of the checks into new macros in c.h, and add commentary about how to use the macros correctly. Back-patch to all supported branches, as we did with the previous fix. Yuya Watari Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com
2019-11-07 17:22:52 +01:00
/* Range check */
if (unlikely(isnan(num) || !FLOAT4_FITS_IN_INT32(num)))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("integer out of range")));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
PG_RETURN_INT32((int32) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
* ftoi2 - converts a float4 number to an int2 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
Datum
ftoi2(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
float4 num = PG_GETARG_FLOAT4(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
/*
* Get rid of any fractional part in the input. This is so we don't fail
* on just-out-of-range values that would round into range. Note
* assumption that rint() will pass through a NaN or Inf unchanged.
*/
num = rint(num);
Fix integer-overflow edge case detection in interval_mul and pgbench. This patch adopts the overflow check logic introduced by commit cbdb8b4c0 into two more places. interval_mul() failed to notice if it computed a new microseconds value that was one more than INT64_MAX, and pgbench's double-to-int64 logic had the same sorts of edge-case problems that cbdb8b4c0 fixed in the core code. To make this easier to get right in future, put the guts of the checks into new macros in c.h, and add commentary about how to use the macros correctly. Back-patch to all supported branches, as we did with the previous fix. Yuya Watari Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com
2019-11-07 17:22:52 +01:00
/* Range check */
if (unlikely(isnan(num) || !FLOAT4_FITS_IN_INT16(num)))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
Detect overflow in integer arithmetic operators (integer, smallint, and bigint variants). Clean up some inconsistencies in error message wording. Fix scanint8 to allow trailing whitespace in INT64_MIN case. Update int8-exp-three-digits.out, which seems to have been ignored by the last couple of people to modify the int8 regression test, and remove int8-exp-three-digits-win32.out which is thereby exposed as redundant.
2004-10-04 16:42:48 +02:00
errmsg("smallint out of range")));
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
Fix float-to-integer coercions to handle edge cases correctly. ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
2018-11-24 02:57:11 +01:00
PG_RETURN_INT16((int16) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
* i4tof - converts an int4 number to a float4 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
Datum
i4tof(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Another batch of fmgr updates. I think I have gotten all old-style functions that take pass-by-value datatypes. Should be ready for port testing ...
2000-06-13 09:35:40 +02:00
int32 num = PG_GETARG_INT32(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT4((float4) num);
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
}
/*
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
* i2tof - converts an int2 number to a float4 number
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
*/
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
Datum
i2tof(PG_FUNCTION_ARGS)
Fix timezone manipulation code to avoid crashes on some machines. Add type conversion functions for floating point numbers. Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). Ensure circle type has non-negative radius.
1997-05-11 17:11:47 +02:00
{
Latest round of fmgr updates. All functions with bool,char, or int2 inputs have been converted to newstyle. This should go a long way towards fixing our portability problems with platforms where char and short parameters are passed differently from int-width parameters. Still more to do for the Alpha port however.
2000-06-05 09:29:25 +02:00
int16 num = PG_GETARG_INT16(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT4((float4) num);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* =======================
* RANDOM FLOAT8 OPERATORS
* =======================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dround - returns ROUND(arg1)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dround(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
PG_RETURN_FLOAT8(rint(arg1));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
This patch adds some missing functions for float8 math operations, specifically ceil(), floor(), and sign(). There may be other functions that need to be added, but this is a start. I've included some simple regression tests. Neil Conway
2002-10-19 04:08:19 +02:00
/*
* dceil - returns the smallest integer greater than or
* equal to the specified float
*/
Datum
dceil(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
PG_RETURN_FLOAT8(ceil(arg1));
}
/*
* dfloor - returns the largest integer lesser than or
* equal to the specified float
*/
Datum
dfloor(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
PG_RETURN_FLOAT8(floor(arg1));
}
/*
* dsign - returns -1 if the argument is less than 0, 0
* if the argument is equal to 0, and 1 if the
* argument is greater than zero.
*/
Datum
dsign(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
if (arg1 > 0)
result = 1.0;
else if (arg1 < 0)
result = -1.0;
else
result = 0.0;
PG_RETURN_FLOAT8(result);
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dtrunc - returns truncation-towards-zero of arg1,
* arg1 >= 0 ... the greatest integer less
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* than or equal to arg1
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* arg1 < 0 ... the least integer greater
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* than or equal to arg1
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dtrunc(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
if (arg1 >= 0)
result = floor(arg1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
else
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = -floor(-arg1);
PG_RETURN_FLOAT8(result);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dsqrt - returns square root of arg1
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dsqrt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
if (arg1 < 0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_POWER_FUNCTION),
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
errmsg("cannot take square root of a negative number")));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = sqrt(arg1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, isinf(arg1), arg1 == 0);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dcbrt - returns cube root of arg1
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dcbrt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = cbrt(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, isinf(arg1), arg1 == 0);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dpow - returns pow(arg1,arg2)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dpow(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
float8 result;
Finally found a platform which has finite() but nonetheless sets errno rather than returning a NaN for bogus input to pow(). Namely, HPUX 10.20. I think this is sufficient evidence for what I thought all along, which is that the float.c code *must* look at errno whether finite() exists or not.
1999-12-20 03:15:35 +01:00
Avoid wrong results for power() with NaN input on more platforms. Buildfarm results show that the modern POSIX rule that 1 ^ NaN = 1 is not honored on *BSD until relatively recently, and really old platforms don't believe that NaN ^ 0 = 1 either. (This is unsurprising, perhaps, since SUSv2 doesn't require either behavior.) In hopes of getting to platform independent behavior, let's deal with all the NaN-input cases explicitly in dpow(). Note that numeric_power() doesn't know either of these special cases. But since that behavior is platform-independent, I think it should be addressed separately, and probably not back-patched. Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
2018-04-30 00:15:16 +02:00
/*
* The POSIX spec says that NaN ^ 0 = 1, and 1 ^ NaN = 1, while all other
* cases with NaN inputs yield NaN (with no error). Many older platforms
* get one or more of these cases wrong, so deal with them via explicit
* logic rather than trusting pow(3).
*/
if (isnan(arg1))
{
if (isnan(arg2) || arg2 != 0.0)
PG_RETURN_FLOAT8(get_float8_nan());
PG_RETURN_FLOAT8(1.0);
}
if (isnan(arg2))
{
if (arg1 != 1.0)
PG_RETURN_FLOAT8(get_float8_nan());
PG_RETURN_FLOAT8(1.0);
}
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* The SQL spec requires that we emit a particular SQLSTATE error code for
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* certain error conditions. Specifically, we don't return a
* divide-by-zero error code for 0 ^ -1.
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
*/
Adjust power() error messages to be more descriptive.
2008-05-09 23:31:23 +02:00
if (arg1 == 0 && arg2 < 0)
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_POWER_FUNCTION),
Adjust power() error messages to be more descriptive.
2008-05-09 23:31:23 +02:00
errmsg("zero raised to a negative power is undefined")));
if (arg1 < 0 && floor(arg2) != arg2)
ereport(ERROR,
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_POWER_FUNCTION),
errmsg("a negative number raised to a non-integer power yields a complex result")));
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
/*
For float4/8, remove errno checks for pow() and exp() because only some platforms set errno, and we already have a check macro that detects under/overflow, so there is no reason for platform-specific code anymore.
2007-01-03 05:21:47 +01:00
* pow() sets errno only on some platforms, depending on whether it
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* follows _IEEE_, _POSIX_, _XOPEN_, or _SVID_, so we try to avoid using
* errno. However, some platform/CPU combinations return errno == EDOM
Avoid wrong results for power() with NaN input on some platforms. Per spec, the result of power() should be NaN if either input is NaN. It appears that on some versions of Windows, the libc function does return NaN, but it also sets errno = EDOM, confusing our code that attempts to work around shortcomings of other platforms. Hence, add guard tests to avoid substituting a wrong result for the right one. It's been like this for a long time (and the odd behavior only appears in older MSVC releases, too) so back-patch to all supported branches. Dang Minh Huong, reviewed by David Rowley Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
2018-04-29 21:21:44 +02:00
* and result == NaN for negative arg1 and very large arg2 (they must be
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* using something different from our floor() test to decide it's
* invalid). Other platforms (HPPA) return errno == ERANGE and a large
Avoid wrong results for power() with NaN input on more platforms. Buildfarm results show that the modern POSIX rule that 1 ^ NaN = 1 is not honored on *BSD until relatively recently, and really old platforms don't believe that NaN ^ 0 = 1 either. (This is unsurprising, perhaps, since SUSv2 doesn't require either behavior.) In hopes of getting to platform independent behavior, let's deal with all the NaN-input cases explicitly in dpow(). Note that numeric_power() doesn't know either of these special cases. But since that behavior is platform-independent, I think it should be addressed separately, and probably not back-patched. Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
2018-04-30 00:15:16 +02:00
* (HUGE_VAL) but finite result to signal overflow.
Finally found a platform which has finite() but nonetheless sets errno rather than returning a NaN for bogus input to pow(). Namely, HPUX 10.20. I think this is sufficient evidence for what I thought all along, which is that the float.c code *must* look at errno whether finite() exists or not.
1999-12-20 03:15:35 +01:00
*/
Attempt to return proper overflow/underflow messages for platforms that only return Nan and set errno for pow/exp overflow/underflow.
2007-01-03 15:35:24 +01:00
errno = 0;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = pow(arg1, arg2);
Avoid wrong results for power() with NaN input on more platforms. Buildfarm results show that the modern POSIX rule that 1 ^ NaN = 1 is not honored on *BSD until relatively recently, and really old platforms don't believe that NaN ^ 0 = 1 either. (This is unsurprising, perhaps, since SUSv2 doesn't require either behavior.) In hopes of getting to platform independent behavior, let's deal with all the NaN-input cases explicitly in dpow(). Note that numeric_power() doesn't know either of these special cases. But since that behavior is platform-independent, I think it should be addressed separately, and probably not back-patched. Discussion: https://postgr.es/m/75DB81BEEA95B445AE6D576A0A5C9E936A73E741@BPXM05GP.gisp.nec.co.jp
2018-04-30 00:15:16 +02:00
if (errno == EDOM && isnan(result))
Attempt to return proper overflow/underflow messages for platforms that only return Nan and set errno for pow/exp overflow/underflow.
2007-01-03 15:35:24 +01:00
{
if ((fabs(arg1) > 1 && arg2 >= 0) || (fabs(arg1) < 1 && arg2 < 0))
Put back ERANGE test in dpow(). There are platforms that need this, like my HPPA ...
2007-01-06 03:28:38 +01:00
/* The sign of Inf is not significant in this case. */
Simplify assignment of Inf for pow Nan (don't worry about the sign).
2007-01-04 06:18:39 +01:00
result = get_float8_infinity();
Update pow() tests to check for both errno==EDOM _and_ result==Nan, and document why this happens. Remove exp() errno check because not needed.
2007-01-03 23:05:00 +01:00
else if (fabs(arg1) != 1)
Attempt to return proper overflow/underflow messages for platforms that only return Nan and set errno for pow/exp overflow/underflow.
2007-01-03 15:35:24 +01:00
result = 0;
Update pow() tests to check for both errno==EDOM _and_ result==Nan, and document why this happens. Remove exp() errno check because not needed.
2007-01-03 23:05:00 +01:00
else
result = 1;
Attempt to return proper overflow/underflow messages for platforms that only return Nan and set errno for pow/exp overflow/underflow.
2007-01-03 15:35:24 +01:00
}
Apply fix so pow() and exp() ERANGE is used only if result is not 0.
2007-01-06 21:21:29 +01:00
else if (errno == ERANGE && result != 0 && !isinf(result))
Improve dpow() check for ERANGE overflow for HPPA.
2007-01-06 05:14:55 +01:00
result = get_float8_infinity();
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, isinf(arg1) || isinf(arg2), arg1 == 0);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dexp - returns the exponential function of arg1
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dexp(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Finally found a platform which has finite() but nonetheless sets errno rather than returning a NaN for bogus input to pow(). Namely, HPUX 10.20. I think this is sufficient evidence for what I thought all along, which is that the float.c code *must* look at errno whether finite() exists or not.
1999-12-20 03:15:35 +01:00
Check for ERANGE in exp() as well. Improve release docs for ecpg regression tests.
2007-01-06 16:18:03 +01:00
errno = 0;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = exp(arg1);
Apply fix so pow() and exp() ERANGE is used only if result is not 0.
2007-01-06 21:21:29 +01:00
if (errno == ERANGE && result != 0 && !isinf(result))
Check for ERANGE in exp() as well. Improve release docs for ecpg regression tests.
2007-01-06 16:18:03 +01:00
result = get_float8_infinity();
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, isinf(arg1), false);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dlog1 - returns the natural logarithm of arg1
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dlog1(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Emit particular SQLSTATE error codes for ln(). This is required by the
* SQL standard.
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
if (arg1 == 0.0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_LOG),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot take logarithm of zero")));
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
if (arg1 < 0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_LOG),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot take logarithm of a negative number")));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = log(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, isinf(arg1), arg1 == 1);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dlog10 - returns the base 10 logarithm of arg1
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dlog10(PG_FUNCTION_ARGS)
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Emit particular SQLSTATE error codes for log(). The SQL spec doesn't
* define log(), but it does define ln(), so it makes sense to emit the
* same error code for an analogous error condition.
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
if (arg1 == 0.0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_LOG),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot take logarithm of zero")));
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
if (arg1 < 0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
Change ln(), log(), power(), and sqrt() to emit the correct SQLSTATE error codes for certain error conditions, as specified by SQL2003.
2004-05-17 01:18:55 +02:00
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_LOG),
Message editing: remove gratuitous variations in message wording, standardize terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
2003-09-25 08:58:07 +02:00
errmsg("cannot take logarithm of a negative number")));
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = log10(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, isinf(arg1), arg1 == 1);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Implement column aliases on views "CREATE VIEW name (collist)". Implement TIME WITH TIME ZONE type (timetz internal type). Remap length() for character strings to CHAR_LENGTH() for SQL92 and to remove the ambiguity with geometric length() functions. Keep length() for character strings for backward compatibility. Shrink stored views by removing internal column name list from visible rte. Implement min(), max() for time and timetz data types. Implement conversion of TIME to INTERVAL. Implement abs(), mod(), fac() for the int8 data type. Rename some math functions to generic names: round(), sqrt(), cbrt(), pow(), etc. Rename NUMERIC power() function to pow(). Fix int2 factorial to calculate result in int4. Enhance the Oracle compatibility function translate() to work with string arguments (from Edwin Ramirez). Modify pg_proc system table to remove OID holes.
2000-03-15 00:06:59 +01:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dacos - returns the arccos of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dacos(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
For float4/8, remove errno checks for pow() and exp() because only some platforms set errno, and we already have a check macro that detects under/overflow, so there is no reason for platform-specific code anymore.
2007-01-03 05:21:47 +01:00
/*
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
* The principal branch of the inverse cosine function maps values in the
* range [-1, 1] to values in the range [0, Pi], so we should reject any
* inputs outside that range and the result will always be finite.
For float4/8, remove errno checks for pow() and exp() because only some platforms set errno, and we already have a check macro that detects under/overflow, so there is no reason for platform-specific code anymore.
2007-01-03 05:21:47 +01:00
*/
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
if (arg1 < -1.0 || arg1 > 1.0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
result = acos(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dasin - returns the arcsin of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dasin(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
/*
* The principal branch of the inverse sine function maps values in the
* range [-1, 1] to values in the range [-Pi/2, Pi/2], so we should reject
* any inputs outside that range and the result will always be finite.
*/
if (arg1 < -1.0 || arg1 > 1.0)
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
result = asin(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* datan - returns the arctan of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
datan(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
/*
* The principal branch of the inverse tangent function maps all inputs to
* values in the range [-Pi/2, Pi/2], so the result should always be
* finite, even if the input is infinite.
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = atan(arg1);
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
* atan2 - returns the arctan of arg1/arg2 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
datan2(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if either input is NaN */
if (isnan(arg1) || isnan(arg2))
PG_RETURN_FLOAT8(get_float8_nan());
/*
* atan2 maps all inputs to values in the range [-Pi, Pi], so the result
* should always be finite, even if the inputs are infinite.
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = atan2(arg1, arg2);
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dcos - returns the cosine of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dcos(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
/*
* cos() is periodic and so theoretically can work for all finite inputs,
* but some implementations may choose to throw error if the input is so
* large that there are no significant digits in the result. So we should
* check for errors. POSIX allows an error to be reported either via
* errno or via fetestexcept(), but currently we only support checking
* errno. (fetestexcept() is rumored to report underflow unreasonably
* early on some platforms, so it's not clear that believing it would be a
* net improvement anyway.)
*
* For infinite inputs, POSIX specifies that the trigonometric functions
* should return a domain error; but we won't notice that unless the
* platform reports via errno, so also explicitly test for infinite
* inputs.
*/
Remove comment on errno=0 lines, but add mention to port/strtol.c function.
2005-12-02 03:49:11 +01:00
errno = 0;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = cos(arg1);
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
if (errno != 0 || isinf(arg1))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dcot - returns the cotangent of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dcot(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
/* Be sure to throw an error if the input is infinite --- see dcos() */
Remove comment on errno=0 lines, but add mention to port/strtol.c function.
2005-12-02 03:49:11 +01:00
errno = 0;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = tan(arg1);
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
if (errno != 0 || isinf(arg1))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = 1.0 / result;
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, true /* cot(0) == Inf */ , true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dsin - returns the sine of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dsin(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
/* Be sure to throw an error if the input is infinite --- see dcos() */
Remove comment on errno=0 lines, but add mention to port/strtol.c function.
2005-12-02 03:49:11 +01:00
errno = 0;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = sin(arg1);
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
if (errno != 0 || isinf(arg1))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dtan - returns the tangent of arg1 (radians)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dtan(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
/* Be sure to throw an error if the input is infinite --- see dcos() */
Remove comment on errno=0 lines, but add mention to port/strtol.c function.
2005-12-02 03:49:11 +01:00
errno = 0;
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
result = tan(arg1);
Improve cross-platform consistency of Inf/NaN handling in trig functions. Ensure that the trig functions return NaN for NaN input regardless of what the underlying C library functions might do. Also ensure that an error is thrown for Inf (or otherwise out-of-range) input, except for atan/atan2 which should accept it. All these behaviors should now conform to the POSIX spec; previously, all our popular platforms deviated from that in one case or another. The main remaining platform dependency here is whether the C library might choose to throw a domain error for sin/cos/tan inputs that are large but less than infinity. (Doing so is not unreasonable, since once a single unit-in-the-last-place exceeds PI, there can be no significance at all in the result; however there doesn't seem to be any suggestion in POSIX that such an error is allowed.) We will report such errors if they are reported via "errno", but not if they are reported via "fetestexcept" which is the other mechanism sanctioned by POSIX. Some preliminary experiments with fetestexcept indicated that it might also report errors we could do without, such as complaining about underflow at an unreasonably large threshold. So let's skip that complexity for now. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 20:50:51 +01:00
if (errno != 0 || isinf(arg1))
Error message editing in utils/adt. Again thanks to Joe Conway for doing the bulk of the heavy lifting ...
2003-07-27 06:53:12 +02:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, true /* tan(pi/2) == Inf */ , true);
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
/* ========== DEGREE-BASED TRIGONOMETRIC FUNCTIONS ========== */
/*
* Initialize the cached constants declared at the head of this file
* (sin_30 etc). The fact that we need those at all, let alone need this
* Rube-Goldberg-worthy method of initializing them, is because there are
* compilers out there that will precompute expressions such as sin(constant)
* using a sin() function different from what will be used at runtime. If we
* want exact results, we must ensure that none of the scaling constants used
New method for preventing compile-time calculation of degree constants. Commit 65abaab547a5758b tried to prevent the scaling constants used in the degree-based trig functions from being precomputed at compile time, because some compilers do that with functions that don't yield results identical-to-the-last-bit to what you get at runtime. A report from Peter Eisentraut suggests that some recent compilers are smart enough to see through that trick, though. Instead, let's put the inputs to these calculations into non-const global variables, which should be a more reliable way of convincing the compiler that it can't assume that they are compile-time constants. (If we really get desperate, we could mark these variables "volatile", but I do not believe we should have to.)
2016-04-25 21:21:04 +02:00
* in the degree-based trig functions are computed that way. To do so, we
* compute them from the variables degree_c_thirty etc, which are also really
* constants, but the compiler cannot assume that.
Still further adjust degree-based trig functions for more portability. Indeed, the non-static declaration foreseen in my previous commit message is necessary. Per Noah Misch.
2016-01-24 00:12:54 +01:00
*
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
* Other hazards we are trying to forestall with this kluge include the
* possibility that compilers will rearrange the expressions, or compute
* some intermediate results in registers wider than a standard double.
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
*
* In the places where we use these constants, the typical pattern is like
* volatile float8 sin_x = sin(x * RADIANS_PER_DEGREE);
* return (sin_x / sin_30);
* where we hope to get a value of exactly 1.0 from the division when x = 30.
* The volatile temporary variable is needed on machines with wide float
* registers, to ensure that the result of sin(x) is rounded to double width
* the same as the value of sin_30 has been. Experimentation with gcc shows
* that marking the temp variable volatile is necessary to make the store and
* reload actually happen; hopefully the same trick works for other compilers.
* (gcc's documentation suggests using the -ffloat-store compiler switch to
* ensure this, but that is compiler-specific and it also pessimizes code in
* many places where we don't care about this.)
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
*/
New method for preventing compile-time calculation of degree constants. Commit 65abaab547a5758b tried to prevent the scaling constants used in the degree-based trig functions from being precomputed at compile time, because some compilers do that with functions that don't yield results identical-to-the-last-bit to what you get at runtime. A report from Peter Eisentraut suggests that some recent compilers are smart enough to see through that trick, though. Instead, let's put the inputs to these calculations into non-const global variables, which should be a more reliable way of convincing the compiler that it can't assume that they are compile-time constants. (If we really get desperate, we could mark these variables "volatile", but I do not believe we should have to.)
2016-04-25 21:21:04 +02:00
static void
init_degree_constants(void)
{
sin_30 = sin(degree_c_thirty * RADIANS_PER_DEGREE);
one_minus_cos_60 = 1.0 - cos(degree_c_sixty * RADIANS_PER_DEGREE);
asin_0_5 = asin(degree_c_one_half);
acos_0_5 = acos(degree_c_one_half);
atan_1_0 = atan(degree_c_one);
tan_45 = sind_q1(degree_c_forty_five) / cosd_q1(degree_c_forty_five);
cot_45 = cosd_q1(degree_c_forty_five) / sind_q1(degree_c_forty_five);
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
degree_consts_set = true;
}
#define INIT_DEGREE_CONSTANTS() \
do { \
if (!degree_consts_set) \
New method for preventing compile-time calculation of degree constants. Commit 65abaab547a5758b tried to prevent the scaling constants used in the degree-based trig functions from being precomputed at compile time, because some compilers do that with functions that don't yield results identical-to-the-last-bit to what you get at runtime. A report from Peter Eisentraut suggests that some recent compilers are smart enough to see through that trick, though. Instead, let's put the inputs to these calculations into non-const global variables, which should be a more reliable way of convincing the compiler that it can't assume that they are compile-time constants. (If we really get desperate, we could mark these variables "volatile", but I do not believe we should have to.)
2016-04-25 21:21:04 +02:00
init_degree_constants(); \
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
} while(0)
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* asind_q1 - returns the inverse sine of x in degrees, for x in
* the range [0, 1]. The result is an angle in the
* first quadrant --- [0, 90] degrees.
*
* For the 3 special case inputs (0, 0.5 and 1), this
* function will return exact values (0, 30 and 90
* degrees respectively).
*/
static double
asind_q1(double x)
{
/*
* Stitch together inverse sine and cosine functions for the ranges [0,
* 0.5] and (0.5, 1]. Each expression below is guaranteed to return
* exactly 30 for x=0.5, so the result is a continuous monotonic function
* over the full range.
*/
if (x <= 0.5)
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
{
volatile float8 asin_x = asin(x);
return (asin_x / asin_0_5) * 30.0;
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
else
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
{
volatile float8 acos_x = acos(x);
return 90.0 - (acos_x / acos_0_5) * 60.0;
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
}
/*
* acosd_q1 - returns the inverse cosine of x in degrees, for x in
* the range [0, 1]. The result is an angle in the
* first quadrant --- [0, 90] degrees.
*
* For the 3 special case inputs (0, 0.5 and 1), this
* function will return exact values (0, 60 and 90
* degrees respectively).
*/
static double
acosd_q1(double x)
{
/*
* Stitch together inverse sine and cosine functions for the ranges [0,
* 0.5] and (0.5, 1]. Each expression below is guaranteed to return
* exactly 60 for x=0.5, so the result is a continuous monotonic function
* over the full range.
*/
if (x <= 0.5)
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
{
volatile float8 asin_x = asin(x);
return 90.0 - (asin_x / asin_0_5) * 30.0;
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
else
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
{
volatile float8 acos_x = acos(x);
return (acos_x / acos_0_5) * 60.0;
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
}
/*
* dacosd - returns the arccos of arg1 (degrees)
*/
Datum
dacosd(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* The principal branch of the inverse cosine function maps values in the
* range [-1, 1] to values in the range [0, 180], so we should reject any
* inputs outside that range and the result will always be finite.
*/
if (arg1 < -1.0 || arg1 > 1.0)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
if (arg1 >= 0.0)
result = acosd_q1(arg1);
else
result = 90.0 + asind_q1(-arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* dasind - returns the arcsin of arg1 (degrees)
*/
Datum
dasind(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* The principal branch of the inverse sine function maps values in the
* range [-1, 1] to values in the range [-90, 90], so we should reject any
* inputs outside that range and the result will always be finite.
*/
if (arg1 < -1.0 || arg1 > 1.0)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
if (arg1 >= 0.0)
result = asind_q1(arg1);
else
result = -asind_q1(-arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* datand - returns the arctan of arg1 (degrees)
*/
Datum
datand(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
volatile float8 atan_arg1;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* Per the POSIX spec, return NaN if the input is NaN */
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* The principal branch of the inverse tangent function maps all inputs to
* values in the range [-90, 90], so the result should always be finite,
* even if the input is infinite. Additionally, we take care to ensure
* than when arg1 is 1, the result is exactly 45.
*/
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
atan_arg1 = atan(arg1);
result = (atan_arg1 / atan_1_0) * 45.0;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* atan2d - returns the arctan of arg1/arg2 (degrees)
*/
Datum
datan2d(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
float8 result;
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
volatile float8 atan2_arg1_arg2;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* Per the POSIX spec, return NaN if either input is NaN */
if (isnan(arg1) || isnan(arg2))
PG_RETURN_FLOAT8(get_float8_nan());
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* atan2d maps all inputs to values in the range [-180, 180], so the
* result should always be finite, even if the inputs are infinite.
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
*
* Note: this coding assumes that atan(1.0) is a suitable scaling constant
* to get an exact result from atan2(). This might well fail on us at
* some point, requiring us to decide exactly what inputs we think we're
* going to guarantee an exact result for.
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
*/
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
atan2_arg1_arg2 = atan2(arg1, arg2);
result = (atan2_arg1_arg2 / atan_1_0) * 45.0;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* sind_0_to_30 - returns the sine of an angle that lies between 0 and
* 30 degrees. This will return exactly 0 when x is 0,
* and exactly 0.5 when x is 30 degrees.
*/
static double
sind_0_to_30(double x)
{
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
volatile float8 sin_x = sin(x * RADIANS_PER_DEGREE);
return (sin_x / sin_30) / 2.0;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
}
/*
* cosd_0_to_60 - returns the cosine of an angle that lies between 0
* and 60 degrees. This will return exactly 1 when x
* is 0, and exactly 0.5 when x is 60 degrees.
*/
static double
cosd_0_to_60(double x)
{
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
volatile float8 one_minus_cos_x = 1.0 - cos(x * RADIANS_PER_DEGREE);
Yet further adjust degree-based trig functions for more portability. Buildfarm member cockatiel is still saying that cosd(60) isn't 0.5. What seems likely is that the subexpression (1.0 - cos(x)) isn't being rounded to double width before more arithmetic is done on it, so force that by storing it into a variable.
2016-01-24 18:53:03 +01:00
return 1.0 - (one_minus_cos_x / one_minus_cos_60) / 2.0;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
}
/*
* sind_q1 - returns the sine of an angle in the first quadrant
* (0 to 90 degrees).
*/
static double
sind_q1(double x)
{
/*
* Stitch together the sine and cosine functions for the ranges [0, 30]
* and (30, 90]. These guarantee to return exact answers at their
* endpoints, so the overall result is a continuous monotonic function
* that gives exact results when x = 0, 30 and 90 degrees.
*/
if (x <= 30.0)
return sind_0_to_30(x);
else
return cosd_0_to_60(90.0 - x);
}
/*
* cosd_q1 - returns the cosine of an angle in the first quadrant
* (0 to 90 degrees).
*/
static double
cosd_q1(double x)
{
/*
* Stitch together the sine and cosine functions for the ranges [0, 60]
* and (60, 90]. These guarantee to return exact answers at their
* endpoints, so the overall result is a continuous monotonic function
* that gives exact results when x = 0, 60 and 90 degrees.
*/
if (x <= 60.0)
return cosd_0_to_60(x);
else
return sind_0_to_30(90.0 - x);
}
/*
* dcosd - returns the cosine of arg1 (degrees)
*/
Datum
dcosd(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
int sign = 1;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* Per the POSIX spec, return NaN if the input is NaN and throw an error
* if the input is infinite.
*/
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
if (isinf(arg1))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* Reduce the range of the input to [0,90] degrees */
arg1 = fmod(arg1, 360.0);
if (arg1 < 0.0)
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
{
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* cosd(-x) = cosd(x) */
arg1 = -arg1;
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
if (arg1 > 180.0)
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
{
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* cosd(360-x) = cosd(x) */
arg1 = 360.0 - arg1;
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
if (arg1 > 90.0)
{
/* cosd(180-x) = -cosd(x) */
arg1 = 180.0 - arg1;
sign = -sign;
}
result = sign * cosd_q1(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* dcotd - returns the cotangent of arg1 (degrees)
*/
Datum
dcotd(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
volatile float8 cot_arg1;
Adjust degree-based trig functions for more portability. The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
2016-01-23 17:26:07 +01:00
int sign = 1;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* Per the POSIX spec, return NaN if the input is NaN and throw an error
* if the input is infinite.
*/
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
if (isinf(arg1))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* Reduce the range of the input to [0,90] degrees */
arg1 = fmod(arg1, 360.0);
if (arg1 < 0.0)
{
/* cotd(-x) = -cotd(x) */
arg1 = -arg1;
sign = -sign;
}
if (arg1 > 180.0)
{
/* cotd(360-x) = -cotd(x) */
arg1 = 360.0 - arg1;
sign = -sign;
}
if (arg1 > 90.0)
{
/* cotd(180-x) = -cotd(x) */
arg1 = 180.0 - arg1;
sign = -sign;
}
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
cot_arg1 = cosd_q1(arg1) / sind_q1(arg1);
result = sign * (cot_arg1 / cot_45);
Adjust degree-based trig functions for more portability. The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
2016-01-23 17:26:07 +01:00
/*
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
* On some machines we get cotd(270) = minus zero, but this isn't always
Adjust degree-based trig functions for more portability. The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
2016-01-23 17:26:07 +01:00
* true. For portability, and because the user constituency for this
* function probably doesn't want minus zero, force it to plain zero.
*/
if (result == 0.0)
result = 0.0;
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, true /* cotd(0) == Inf */ , true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* dsind - returns the sine of arg1 (degrees)
*/
Datum
dsind(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
int sign = 1;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* Per the POSIX spec, return NaN if the input is NaN and throw an error
* if the input is infinite.
*/
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
if (isinf(arg1))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* Reduce the range of the input to [0,90] degrees */
arg1 = fmod(arg1, 360.0);
if (arg1 < 0.0)
{
/* sind(-x) = -sind(x) */
arg1 = -arg1;
sign = -sign;
}
if (arg1 > 180.0)
{
/* sind(360-x) = -sind(x) */
arg1 = 360.0 - arg1;
sign = -sign;
}
if (arg1 > 90.0)
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
{
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* sind(180-x) = sind(x) */
arg1 = 180.0 - arg1;
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
}
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
result = sign * sind_q1(arg1);
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, false, true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
/*
* dtand - returns the tangent of arg1 (degrees)
*/
Datum
dtand(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
volatile float8 tan_arg1;
Adjust degree-based trig functions for more portability. The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
2016-01-23 17:26:07 +01:00
int sign = 1;
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/*
* Per the POSIX spec, return NaN if the input is NaN and throw an error
* if the input is infinite.
*/
if (isnan(arg1))
PG_RETURN_FLOAT8(get_float8_nan());
if (isinf(arg1))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
INIT_DEGREE_CONSTANTS();
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
/* Reduce the range of the input to [0,90] degrees */
arg1 = fmod(arg1, 360.0);
if (arg1 < 0.0)
{
/* tand(-x) = -tand(x) */
arg1 = -arg1;
sign = -sign;
}
if (arg1 > 180.0)
{
/* tand(360-x) = -tand(x) */
arg1 = 360.0 - arg1;
sign = -sign;
}
if (arg1 > 90.0)
{
/* tand(180-x) = -tand(x) */
arg1 = 180.0 - arg1;
sign = -sign;
}
Yet more portability hacking for degree-based trig functions. The true explanation for Peter Eisentraut's report of inexact asind results seems to be that (a) he's compiling into x87 instruction set, which uses wider-than-double float registers, plus (b) the library function asin() on his platform returns a result that is wider than double and is not rounded to double width. To fix, we have to force the function's result to be rounded comparably to what happened to the scaling constant asin_0_5. Experimentation suggests that storing it into a volatile local variable is the least ugly way of making that happen. Although only asin() is known to exhibit an observable inexact result, we'd better do this in all the places where we're hoping to get an exact result by scaling.
2016-04-26 17:24:15 +02:00
tan_arg1 = sind_q1(arg1) / cosd_q1(arg1);
result = sign * (tan_arg1 / tan_45);
Adjust degree-based trig functions for more portability. The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
2016-01-23 17:26:07 +01:00
/*
Further adjust degree-based trig functions for more portability. The last round didn't do it. Per Noah Misch, the problem on at least some machines is that the compiler pre-evaluates trig functions having constant arguments using code slightly different from what will be used at runtime. Therefore, we must prevent the compiler from seeing constant arguments to any of the libm trig functions used in this code. The method used here might still fail if init_degree_constants() gets inlined into the call sites. That probably won't happen given the large number of call sites; but if it does, we could probably fix it by making init_degree_constants() non-static. I'll avoid that till proven necessary, though.
2016-01-23 22:17:31 +01:00
* On some machines we get tand(180) = minus zero, but this isn't always
Adjust degree-based trig functions for more portability. The buildfarm isn't very happy with the results of commit e1bd684a34c11139. To try to get the expected exact results everywhere: * Replace M_PI / 180 subexpressions with a precomputed constant, so that the compiler can't decide to rearrange that division with an adjacent operation. Hopefully this will fix failures to get exactly 0.5 from sind(30) and cosd(60). * Add scaling to ensure that tand(45) and cotd(45) give exactly 1; there was nothing particularly guaranteeing that before. * Replace minus zero by zero when tand() or cotd() would output that; many machines did so for tand(180) and cotd(270), but not all. We could alternatively deem both results valid, but that doesn't seem likely to be what users will want.
2016-01-23 17:26:07 +01:00
* true. For portability, and because the user constituency for this
* function probably doesn't want minus zero, force it to plain zero.
*/
if (result == 0.0)
result = 0.0;
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
check_float8_val(result, true /* tand(90) == Inf */ , true);
Add trigonometric functions that work in degrees. The implementations go to some lengths to deliver exact results for values where an exact result can be expected, such as sind(30) = 0.5 exactly. Dean Rasheed, reviewed by Michael Paquier
2016-01-22 21:46:22 +01:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* degrees - returns degrees converted from radians
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
degrees(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_div(arg1, RADIANS_PER_DEGREE));
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* dpi - returns the constant PI
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
dpi(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(M_PI);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* radians - returns radians converted from degrees
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
radians(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mul(arg1, RADIANS_PER_DEGREE));
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Add support for hyperbolic functions, as well as log10(). The SQL:2016 standard adds support for the hyperbolic functions sinh(), cosh(), and tanh(). POSIX has long required libm to provide those functions as well as their inverses asinh(), acosh(), atanh(). Hence, let's just expose the libm functions to the SQL level. As with the trig functions, we only implement versions for float8, not numeric. For the moment, we'll assume that all platforms actually do have these functions; if experience teaches otherwise, some autoconf effort may be needed. SQL:2016 also adds support for base-10 logarithm, but with the function name log10(), whereas the name we've long used is log(). Add aliases named log10() for the float8 and numeric versions. Lætitia Avrot Discussion: https://postgr.es/m/CAB_COdguG22LO=rnxDQ2DW1uzv8aQoUzyDQNJjrR4k00XSgm5w@mail.gmail.com
2019-03-12 20:55:09 +01:00
/* ========== HYPERBOLIC FUNCTIONS ========== */
/*
* dsinh - returns the hyperbolic sine of arg1
*/
Datum
dsinh(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
errno = 0;
result = sinh(arg1);
/*
* if an ERANGE error occurs, it means there is an overflow. For sinh,
* the result should be either -infinity or infinity, depending on the
* sign of arg1.
*/
if (errno == ERANGE)
{
if (arg1 < 0)
result = -get_float8_infinity();
else
result = get_float8_infinity();
}
check_float8_val(result, true, true);
PG_RETURN_FLOAT8(result);
}
/*
* dcosh - returns the hyperbolic cosine of arg1
*/
Datum
dcosh(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
errno = 0;
result = cosh(arg1);
/*
* if an ERANGE error occurs, it means there is an overflow. As cosh is
* always positive, it always means the result is positive infinity.
*/
if (errno == ERANGE)
result = get_float8_infinity();
check_float8_val(result, true, false);
PG_RETURN_FLOAT8(result);
}
/*
* dtanh - returns the hyperbolic tangent of arg1
*/
Datum
dtanh(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
/*
* For tanh, we don't need an errno check because it never overflows.
*/
result = tanh(arg1);
check_float8_val(result, false, true);
PG_RETURN_FLOAT8(result);
}
/*
* dasinh - returns the inverse hyperbolic sine of arg1
*/
Datum
dasinh(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
/*
* For asinh, we don't need an errno check because it never overflows.
*/
result = asinh(arg1);
check_float8_val(result, true, true);
PG_RETURN_FLOAT8(result);
}
/*
* dacosh - returns the inverse hyperbolic cosine of arg1
*/
Datum
dacosh(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
/*
* acosh is only defined for inputs >= 1.0. By checking this ourselves,
* we need not worry about checking for an EDOM error, which is a good
* thing because some implementations will report that for NaN. Otherwise,
* no error is possible.
*/
if (arg1 < 1.0)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
result = acosh(arg1);
check_float8_val(result, true, true);
PG_RETURN_FLOAT8(result);
}
/*
* datanh - returns the inverse hyperbolic tangent of arg1
*/
Datum
datanh(PG_FUNCTION_ARGS)
{
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
/*
* atanh is only defined for inputs between -1 and 1. By checking this
* ourselves, we need not worry about checking for an EDOM error, which is
* a good thing because some implementations will report that for NaN.
*/
if (arg1 < -1.0 || arg1 > 1.0)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
/*
* Also handle the infinity cases ourselves; this is helpful because old
* glibc versions may produce the wrong errno for this. All other inputs
* cannot produce an error.
*/
if (arg1 == -1.0)
result = -get_float8_infinity();
else if (arg1 == 1.0)
result = get_float8_infinity();
else
result = atanh(arg1);
check_float8_val(result, true, true);
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
* drandom - returns a random number
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
drandom(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 result;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
/* Initialize random seed, if not done yet in this process */
if (unlikely(!drandom_seed_set))
{
/*
* If possible, initialize the seed using high-quality random bits.
* Should that fail for some reason, we fall back on a lower-quality
* seed based on current time and PID.
*/
Remove configure switch --disable-strong-random This removes a portion of infrastructure introduced by fe0a0b5 to allow compilation of Postgres in environments where no strong random source is available, meaning that there is no linking to OpenSSL and no /dev/urandom (Windows having its own CryptoAPI). No systems shipped this century lack /dev/urandom, and the buildfarm is actually not testing this switch at all, so just remove it. This simplifies particularly some backend code which included a fallback implementation using shared memory, and removes a set of alternate regression output files from pgcrypto. Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20181230063219.GG608@paquier.xyz
2019-01-01 12:05:51 +01:00
if (!pg_strong_random(drandom_seed, sizeof(drandom_seed)))
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
{
TimestampTz now = GetCurrentTimestamp();
uint64 iseed;
/* Mix the PID with the most predictable bits of the timestamp */
iseed = (uint64) now ^ ((uint64) MyProcPid << 32);
drandom_seed[0] = (unsigned short) iseed;
drandom_seed[1] = (unsigned short) (iseed >> 16);
drandom_seed[2] = (unsigned short) (iseed >> 32);
}
drandom_seed_set = true;
}
/* pg_erand48 produces desired result range [0.0 - 1.0) */
result = pg_erand48(drandom_seed);
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
PG_RETURN_FLOAT8(result);
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
/*
* setseed - set seed for the random number generator
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
setseed(PG_FUNCTION_ARGS)
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 seed = PG_GETARG_FLOAT8(0);
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
uint64 iseed;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Use a separate random seed for SQL random()/setseed() functions. Previously, the SQL random() function depended on libc's random(3), and setseed() invoked srandom(3). This results in interference between these functions and backend-internal uses of random(3). We'd never paid too much mind to that, but in the wake of commit 88bdbd3f7 which added log_statement_sample_rate, the interference arguably has a security consequence: if log_statement_sample_rate is active then an unprivileged user could probably control which if any of his SQL commands get logged, by issuing setseed() at the right times. That seems bad. To fix this reliably, we need random() and setseed() to use their own private random state variable. Standard random(3) isn't amenable to such usage, so let's switch to pg_erand48(). It's hard to say whether that's more or less "random" than any particular platform's version of random(3), but it does have a wider seed value and a longer period than are required by POSIX, so we can hope that this isn't a big downgrade. Also, we should now have uniform behavior of random() across platforms, which is worth something. While at it, upgrade the per-process seed initialization method to use pg_strong_random() if available, greatly reducing the predictability of the initial seed value. (I'll separately do something similar for the internal uses of random().) In addition to forestalling the possible security problem, this has a benefit in the other direction, which is that we can now document setseed() as guaranteeing a reproducible sequence of random() values. Previously, because of the possibility of internal calls of random(3), we could not promise any such thing. Discussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us
2018-12-29 23:33:27 +01:00
if (seed < -1 || seed > 1 || isnan(seed))
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("setseed parameter %g is out of allowed range [-1,1]",
seed)));
/* Use sign bit + 47 fractional bits to fill drandom_seed[] */
iseed = (int64) (seed * (float8) UINT64CONST(0x7FFFFFFFFFFF));
drandom_seed[0] = (unsigned short) iseed;
drandom_seed[1] = (unsigned short) (iseed >> 16);
drandom_seed[2] = (unsigned short) (iseed >> 32);
drandom_seed_set = true;
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Make setseed() return void, rather than an int4 without any use. Per pgsql-patches discussion of September 20, 2006. Bump the catversion.
2007-01-20 22:47:10 +01:00
PG_RETURN_VOID();
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
}
Add transcendental math functions (sine, cosine, etc) Add a random number generator and seed setter (random(), SET SEED) Fix up the interval*float8 math to carry partial months into the time field. Add float8*interval so we have symmetry in the available math. Fix the parser and define.c to accept SQL92 types as field arguments. Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is necessary to allow... Bit/varbit support in contrib/bit cleaned up to compile and load cleanly. Still needs some work before final release. Implement the "SOME" keyword as a synonym for "ANY" per SQL92. Implement ascii(text), ichar(int4), repeat(text,int4) to help support the ODBC driver. Enable the TRUNCATE() function mapping in the ODBC driver.
2000-04-07 15:40:45 +02:00
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/*
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
* =========================
* FLOAT AGGREGATE OPERATORS
* =========================
*
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
* float8_accum - accumulate for AVG(), variance aggregates, etc.
* float4_accum - same, but input data is float4
* float8_avg - produce final result for float AVG()
* float8_var_samp - produce final result for float VAR_SAMP()
* float8_var_pop - produce final result for float VAR_POP()
* float8_stddev_samp - produce final result for float STDDEV_SAMP()
* float8_stddev_pop - produce final result for float STDDEV_POP()
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
*
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
* The naive schoolbook implementation of these aggregates works by
* accumulating sum(X) and sum(X^2). However, this approach suffers from
* large rounding errors in the final computation of quantities like the
* population variance (N*sum(X^2) - sum(X)^2) / N^2, since each of the
* intermediate terms is potentially very large, while the difference is often
* quite small.
*
* Instead we use the Youngs-Cramer algorithm [1] which works by accumulating
* Sx=sum(X) and Sxx=sum((X-Sx/N)^2), using a numerically stable algorithm to
* incrementally update those quantities. The final computations of each of
* the aggregate values is then trivial and gives more accurate results (for
* example, the population variance is just Sxx/N). This algorithm is also
* fairly easy to generalize to allow parallel execution without loss of
* precision (see, for example, [2]). For more details, and a comparison of
* this with other algorithms, see [3].
*
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
* The transition datatype for all these aggregates is a 3-element array
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
* of float8, holding the values N, Sx, Sxx in that order.
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
*
* Note that we represent N as a float to avoid having to build a special
* datatype. Given a reasonable floating-point implementation, there should
* be no accuracy loss unless N exceeds 2 ^ 52 or so (by which time the
* user will have doubtless lost interest anyway...)
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
*
* [1] Some Results Relevant to Choice of Sum and Sum-of-Product Algorithms,
* E. A. Youngs and E. M. Cramer, Technometrics Vol 13, No 3, August 1971.
*
* [2] Updating Formulae and a Pairwise Algorithm for Computing Sample
* Variances, T. F. Chan, G. H. Golub & R. J. LeVeque, COMPSTAT 1982.
*
* [3] Numerically Stable Parallel Computation of (Co-)Variance, Erich
* Schubert and Michael Gertz, Proceedings of the 30th International
* Conference on Scientific and Statistical Database Management, 2018.
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
*/
static float8 *
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
check_float8_array(ArrayType *transarray, const char *caller, int n)
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
{
/*
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
* We expect the input to be an N-element float array; verify that. We
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
* don't need to use deconstruct_array() since the array data is just
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
* going to look like a C array of N float8 values.
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
*/
Modify array operations to include array's element type OID in the array header, and to compute sizing and alignment of array elements the same way normal tuple access operations do --- viz, using the tupmacs.h macros att_addlength and att_align. This makes the world safe for arrays of cstrings or intervals, and should make it much easier to write array-type-polymorphic functions; as examples see the cleanups of array_out and contrib/array_iterator. By Joe Conway and Tom Lane.
2002-08-26 19:54:02 +02:00
if (ARR_NDIM(transarray) != 1 ||
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
ARR_DIMS(transarray)[0] != n ||
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
ARR_HASNULL(transarray) ||
Modify array operations to include array's element type OID in the array header, and to compute sizing and alignment of array elements the same way normal tuple access operations do --- viz, using the tupmacs.h macros att_addlength and att_align. This makes the world safe for arrays of cstrings or intervals, and should make it much easier to write array-type-polymorphic functions; as examples see the cleanups of array_out and contrib/array_iterator. By Joe Conway and Tom Lane.
2002-08-26 19:54:02 +02:00
ARR_ELEMTYPE(transarray) != FLOAT8OID)
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
elog(ERROR, "%s: expected %d-element float8 array", caller, n);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
return (float8 *) ARR_DATA_PTR(transarray);
}
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
/*
* float8_combine
*
* An aggregate combine function used to combine two 3 fields
* aggregate transition data into a single transition data.
* This function is used only in two stage aggregation and
* shouldn't be called outside aggregate context.
*/
Datum
float8_combine(PG_FUNCTION_ARGS)
{
ArrayType *transarray1 = PG_GETARG_ARRAYTYPE_P(0);
ArrayType *transarray2 = PG_GETARG_ARRAYTYPE_P(1);
float8 *transvalues1;
float8 *transvalues2;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
float8 N1,
Sx1,
Sxx1,
N2,
Sx2,
Sxx2,
tmp,
N,
Sx,
Sxx;
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
transvalues1 = check_float8_array(transarray1, "float8_combine", 3);
transvalues2 = check_float8_array(transarray2, "float8_combine", 3);
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
N1 = transvalues1[0];
Sx1 = transvalues1[1];
Sxx1 = transvalues1[2];
N2 = transvalues2[0];
Sx2 = transvalues2[1];
Sxx2 = transvalues2[2];
/*--------------------
* The transition values combine using a generalization of the
* Youngs-Cramer algorithm as follows:
*
* N = N1 + N2
* Sx = Sx1 + Sx2
* Sxx = Sxx1 + Sxx2 + N1 * N2 * (Sx1/N1 - Sx2/N2)^2 / N;
*
* It's worth handling the special cases N1 = 0 and N2 = 0 separately
* since those cases are trivial, and we then don't need to worry about
* division-by-zero errors in the general case.
*--------------------
*/
if (N1 == 0.0)
{
N = N2;
Sx = Sx2;
Sxx = Sxx2;
}
else if (N2 == 0.0)
{
N = N1;
Sx = Sx1;
Sxx = Sxx1;
}
else
{
N = N1 + N2;
Sx = float8_pl(Sx1, Sx2);
tmp = Sx1 / N1 - Sx2 / N2;
Sxx = Sxx1 + Sxx2 + N1 * N2 * tmp * tmp / N;
check_float8_val(Sxx, isinf(Sxx1) || isinf(Sxx2), true);
}
/*
* If we're invoked as an aggregate, we can cheat and modify our first
* parameter in-place to reduce palloc overhead. Otherwise we construct a
* new array with the updated transition data and return it.
*/
if (AggCheckCallContext(fcinfo, NULL))
{
transvalues1[0] = N;
transvalues1[1] = Sx;
transvalues1[2] = Sxx;
PG_RETURN_ARRAYTYPE_P(transarray1);
}
else
{
Datum transdatums[3];
ArrayType *result;
transdatums[0] = Float8GetDatumFast(N);
transdatums[1] = Float8GetDatumFast(Sx);
transdatums[2] = Float8GetDatumFast(Sxx);
result = construct_array(transdatums, 3,
FLOAT8OID,
sizeof(float8), FLOAT8PASSBYVAL, 'd');
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_ARRAYTYPE_P(result);
}
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
}
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Datum
float8_accum(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 newval = PG_GETARG_FLOAT8(1);
float8 *transvalues;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
float8 N,
Sx,
Sxx,
tmp;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_accum", 3);
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
N = transvalues[0];
Sx = transvalues[1];
Sxx = transvalues[2];
/*
* Use the Youngs-Cramer algorithm to incorporate the new value into the
* transition values.
*/
N += 1.0;
Sx += newval;
if (transvalues[0] > 0.0)
{
tmp = newval * N - Sx;
Sxx += tmp * tmp / (N * transvalues[0]);
/*
* Overflow check. We only report an overflow error when finite
* inputs lead to infinite results. Note also that Sxx should be NaN
* if any of the inputs are infinite, so we intentionally prevent Sxx
* from becoming infinite.
*/
if (isinf(Sx) || isinf(Sxx))
{
if (!isinf(transvalues[1]) && !isinf(newval))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("value out of range: overflow")));
Sxx = get_float8_nan();
}
}
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
/*
Create an official API function for C functions to use to check if they are being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
2010-02-08 21:39:52 +01:00
* If we're invoked as an aggregate, we can cheat and modify our first
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* parameter in-place to reduce palloc overhead. Otherwise we construct a
* new array with the updated transition data and return it.
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
*/
Create an official API function for C functions to use to check if they are being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
2010-02-08 21:39:52 +01:00
if (AggCheckCallContext(fcinfo, NULL))
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
{
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
transvalues[0] = N;
transvalues[1] = Sx;
transvalues[2] = Sxx;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
PG_RETURN_ARRAYTYPE_P(transarray);
}
else
{
Datum transdatums[3];
ArrayType *result;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
transdatums[0] = Float8GetDatumFast(N);
transdatums[1] = Float8GetDatumFast(Sx);
transdatums[2] = Float8GetDatumFast(Sxx);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
result = construct_array(transdatums, 3,
FLOAT8OID,
Allow float8, int8, and related datatypes to be passed by value on machines where Datum is 8 bytes wide. Since this will break old-style C functions (those still using version 0 calling convention) that have arguments or results of these types, provide a configure option to disable it and retain the old pass-by-reference behavior. Likewise, provide a configure option to disable the recently-committed float4 pass-by-value change. Zoltan Boszormenyi, plus configurability stuff by me.
2008-04-21 02:26:47 +02:00
sizeof(float8), FLOAT8PASSBYVAL, 'd');
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
PG_RETURN_ARRAYTYPE_P(result);
}
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
}
Datum
float4_accum(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Fix float4/8 to handle Infinity and Nan consistently, e.g. Infinity is a valid result from a computation if one of the input values was infinity. The previous code assumed an operation that returned infinity was an overflow. Handle underflow/overflow consistently, and add checks for aggregate overflow. Consistently prevent Inf/Nan from being cast to integer data types. Fix INT_MIN % -1 to prevent overflow. Update regression results for new error text. Per report from Roman Kononov.
2007-01-02 21:00:50 +01:00
/* do computations as float8 */
float8 newval = PG_GETARG_FLOAT4(1);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
float8 *transvalues;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
float8 N,
Sx,
Sxx,
tmp;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float4_accum", 3);
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
N = transvalues[0];
Sx = transvalues[1];
Sxx = transvalues[2];
/*
* Use the Youngs-Cramer algorithm to incorporate the new value into the
* transition values.
*/
N += 1.0;
Sx += newval;
if (transvalues[0] > 0.0)
{
tmp = newval * N - Sx;
Sxx += tmp * tmp / (N * transvalues[0]);
/*
* Overflow check. We only report an overflow error when finite
* inputs lead to infinite results. Note also that Sxx should be NaN
* if any of the inputs are infinite, so we intentionally prevent Sxx
* from becoming infinite.
*/
if (isinf(Sx) || isinf(Sxx))
{
if (!isinf(transvalues[1]) && !isinf(newval))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("value out of range: overflow")));
Sxx = get_float8_nan();
}
}
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
/*
Create an official API function for C functions to use to check if they are being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
2010-02-08 21:39:52 +01:00
* If we're invoked as an aggregate, we can cheat and modify our first
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* parameter in-place to reduce palloc overhead. Otherwise we construct a
* new array with the updated transition data and return it.
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
*/
Create an official API function for C functions to use to check if they are being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
2010-02-08 21:39:52 +01:00
if (AggCheckCallContext(fcinfo, NULL))
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
{
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
transvalues[0] = N;
transvalues[1] = Sx;
transvalues[2] = Sxx;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
PG_RETURN_ARRAYTYPE_P(transarray);
}
else
{
Datum transdatums[3];
ArrayType *result;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
transdatums[0] = Float8GetDatumFast(N);
transdatums[1] = Float8GetDatumFast(Sx);
transdatums[2] = Float8GetDatumFast(Sxx);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
result = construct_array(transdatums, 3,
FLOAT8OID,
Allow float8, int8, and related datatypes to be passed by value on machines where Datum is 8 bytes wide. Since this will break old-style C functions (those still using version 0 calling convention) that have arguments or results of these types, provide a configure option to disable it and retain the old pass-by-reference behavior. Likewise, provide a configure option to disable the recently-committed float4 pass-by-value change. Zoltan Boszormenyi, plus configurability stuff by me.
2008-04-21 02:26:47 +02:00
sizeof(float8), FLOAT8PASSBYVAL, 'd');
Apply the "nodeAgg" optimization to more of the builtin transition functions. This patch optimizes int2_sum(), int4_sum(), float4_accum() and float8_accum() to avoid needing to copy the transition function's state for each input tuple of the aggregate. In an extreme case (e.g. SELECT sum(int2_col) FROM table where table has a single column), it improves performance by about 20%. For more complex queries or tables with wider rows, the relative performance improvement will not be as significant.
2005-04-07 01:56:07 +02:00
PG_RETURN_ARRAYTYPE_P(result);
}
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
}
Datum
float8_avg(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_avg", 3);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx = transvalues[1];
/* ignore Sxx */
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Clean up references to SQL92 In most cases, these were just references to the SQL standard in general. In a few cases, a contrast was made between SQL92 and later standards -- those have been kept unchanged.
2013-04-20 17:04:41 +02:00
/* SQL defines AVG of no values to be NULL */
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
if (N == 0.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sx / N);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
}
Datum
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
float8_var_pop(PG_FUNCTION_ARGS)
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_var_pop", 3);
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* ignore Sx */
Sxx = transvalues[2];
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
/* Population variance is undefined when N is 0, so return NULL */
if (N == 0.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxx / N);
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
}
Datum
float8_var_samp(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx;
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_var_samp", 3);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* ignore Sx */
Sxx = transvalues[2];
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
stddev() and variance() should return NULL when there is just one input value, per recent discussion on pgsql-general.
2003-04-21 02:22:24 +02:00
/* Sample variance is undefined when N is 0 or 1, so return NULL */
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
if (N <= 1.0)
stddev() and variance() should return NULL when there is just one input value, per recent discussion on pgsql-general.
2003-04-21 02:22:24 +02:00
PG_RETURN_NULL();
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
Repair roundoff-error problem for stddev/variance results near zero, per complaint from Kemin Zhou. Fix lack of precision in numeric stddev/variance.
2001-12-11 03:02:12 +01:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxx / (N - 1.0));
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
}
Datum
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
float8_stddev_pop(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx;
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_stddev_pop", 3);
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* ignore Sx */
Sxx = transvalues[2];
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
/* Population stddev is undefined when N is 0, so return NULL */
if (N == 0.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(sqrt(Sxx / N));
Implement 4 new aggregate functions from SQL2003. Specifically: var_pop(), var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp() are just renamings of the historical Postgres aggregates variance() and stddev() -- the latter names have been kept for backward compatibility. This patch includes updates for the documentation and regression tests. The catversion has been bumped. NB: SQL2003 requires that DISTINCT not be specified for any of these aggregates. Per discussion on -patches, I have NOT implemented this restriction: if the user asks for stddev(DISTINCT x), presumably they know what they are doing.
2006-03-10 21:15:28 +01:00
}
Datum
float8_stddev_samp(PG_FUNCTION_ARGS)
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx;
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_stddev_samp", 3);
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* ignore Sx */
Sxx = transvalues[2];
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
stddev() and variance() should return NULL when there is just one input value, per recent discussion on pgsql-general.
2003-04-21 02:22:24 +02:00
/* Sample stddev is undefined when N is 0 or 1, so return NULL */
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
if (N <= 1.0)
stddev() and variance() should return NULL when there is just one input value, per recent discussion on pgsql-general.
2003-04-21 02:22:24 +02:00
PG_RETURN_NULL();
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
Repair roundoff-error problem for stddev/variance results near zero, per complaint from Kemin Zhou. Fix lack of precision in numeric stddev/variance.
2001-12-11 03:02:12 +01:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(sqrt(Sxx / (N - 1.0)));
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
}
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/*
* =========================
* SQL2003 BINARY AGGREGATES
* =========================
*
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
* As with the preceding aggregates, we use the Youngs-Cramer algorithm to
* reduce rounding errors in the aggregate final functions.
*
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
* The transition datatype for all these aggregates is a 6-element array of
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
* float8, holding the values N, Sx=sum(X), Sxx=sum((X-Sx/N)^2), Sy=sum(Y),
* Syy=sum((Y-Sy/N)^2), Sxy=sum((X-Sx/N)*(Y-Sy/N)) in that order.
*
* Note that Y is the first argument to all these aggregates!
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
*
* It might seem attractive to optimize this by having multiple accumulator
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* functions that only calculate the sums actually needed. But on most
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
* modern machines, a couple of extra floating-point multiplies will be
* insignificant compared to the other per-tuple overhead, so I've chosen
* to minimize code space instead.
*/
Datum
float8_regr_accum(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 newvalY = PG_GETARG_FLOAT8(1);
float8 newvalX = PG_GETARG_FLOAT8(2);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx,
Sxx,
Sy,
Syy,
Sxy,
tmpX,
tmpY,
scale;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_accum", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx = transvalues[1];
Sxx = transvalues[2];
Sy = transvalues[3];
Syy = transvalues[4];
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/*
* Use the Youngs-Cramer algorithm to incorporate the new values into the
* transition values.
*/
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
N += 1.0;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx += newvalX;
Sy += newvalY;
if (transvalues[0] > 0.0)
{
tmpX = newvalX * N - Sx;
tmpY = newvalY * N - Sy;
scale = 1.0 / (N * transvalues[0]);
Sxx += tmpX * tmpX * scale;
Syy += tmpY * tmpY * scale;
Sxy += tmpX * tmpY * scale;
/*
* Overflow check. We only report an overflow error when finite
* inputs lead to infinite results. Note also that Sxx, Syy and Sxy
* should be NaN if any of the relevant inputs are infinite, so we
* intentionally prevent them from becoming infinite.
*/
if (isinf(Sx) || isinf(Sxx) || isinf(Sy) || isinf(Syy) || isinf(Sxy))
{
if (((isinf(Sx) || isinf(Sxx)) &&
!isinf(transvalues[1]) && !isinf(newvalX)) ||
((isinf(Sy) || isinf(Syy)) &&
!isinf(transvalues[3]) && !isinf(newvalY)) ||
(isinf(Sxy) &&
!isinf(transvalues[1]) && !isinf(newvalX) &&
!isinf(transvalues[3]) && !isinf(newvalY)))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("value out of range: overflow")));
if (isinf(Sxx))
Sxx = get_float8_nan();
if (isinf(Syy))
Syy = get_float8_nan();
if (isinf(Sxy))
Sxy = get_float8_nan();
}
}
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/*
Create an official API function for C functions to use to check if they are being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
2010-02-08 21:39:52 +01:00
* If we're invoked as an aggregate, we can cheat and modify our first
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
* parameter in-place to reduce palloc overhead. Otherwise we construct a
* new array with the updated transition data and return it.
*/
Create an official API function for C functions to use to check if they are being called as aggregates, and to get the aggregate transition state memory context if needed. Use it instead of poking directly into AggState and WindowAggState in places that shouldn't know so much. We should have done this in 8.4, probably, but better late than never. Revised version of a patch by Hitoshi Harada.
2010-02-08 21:39:52 +01:00
if (AggCheckCallContext(fcinfo, NULL))
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
{
transvalues[0] = N;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
transvalues[1] = Sx;
transvalues[2] = Sxx;
transvalues[3] = Sy;
transvalues[4] = Syy;
transvalues[5] = Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_ARRAYTYPE_P(transarray);
}
else
{
Datum transdatums[6];
ArrayType *result;
transdatums[0] = Float8GetDatumFast(N);
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
transdatums[1] = Float8GetDatumFast(Sx);
transdatums[2] = Float8GetDatumFast(Sxx);
transdatums[3] = Float8GetDatumFast(Sy);
transdatums[4] = Float8GetDatumFast(Syy);
transdatums[5] = Float8GetDatumFast(Sxy);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
result = construct_array(transdatums, 6,
FLOAT8OID,
Allow float8, int8, and related datatypes to be passed by value on machines where Datum is 8 bytes wide. Since this will break old-style C functions (those still using version 0 calling convention) that have arguments or results of these types, provide a configure option to disable it and retain the old pass-by-reference behavior. Likewise, provide a configure option to disable the recently-committed float4 pass-by-value change. Zoltan Boszormenyi, plus configurability stuff by me.
2008-04-21 02:26:47 +02:00
sizeof(float8), FLOAT8PASSBYVAL, 'd');
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_ARRAYTYPE_P(result);
}
}
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
/*
* float8_regr_combine
*
* An aggregate combine function used to combine two 6 fields
* aggregate transition data into a single transition data.
* This function is used only in two stage aggregation and
* shouldn't be called outside aggregate context.
*/
Datum
float8_regr_combine(PG_FUNCTION_ARGS)
{
ArrayType *transarray1 = PG_GETARG_ARRAYTYPE_P(0);
ArrayType *transarray2 = PG_GETARG_ARRAYTYPE_P(1);
float8 *transvalues1;
float8 *transvalues2;
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
float8 N1,
Sx1,
Sxx1,
Sy1,
Syy1,
Sxy1,
N2,
Sx2,
Sxx2,
Sy2,
Syy2,
Sxy2,
tmp1,
tmp2,
N,
Sx,
Sxx,
Sy,
Syy,
Sxy;
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
transvalues1 = check_float8_array(transarray1, "float8_regr_combine", 6);
transvalues2 = check_float8_array(transarray2, "float8_regr_combine", 6);
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
N1 = transvalues1[0];
Sx1 = transvalues1[1];
Sxx1 = transvalues1[2];
Sy1 = transvalues1[3];
Syy1 = transvalues1[4];
Sxy1 = transvalues1[5];
N2 = transvalues2[0];
Sx2 = transvalues2[1];
Sxx2 = transvalues2[2];
Sy2 = transvalues2[3];
Syy2 = transvalues2[4];
Sxy2 = transvalues2[5];
/*--------------------
* The transition values combine using a generalization of the
* Youngs-Cramer algorithm as follows:
*
* N = N1 + N2
* Sx = Sx1 + Sx2
* Sxx = Sxx1 + Sxx2 + N1 * N2 * (Sx1/N1 - Sx2/N2)^2 / N
* Sy = Sy1 + Sy2
* Syy = Syy1 + Syy2 + N1 * N2 * (Sy1/N1 - Sy2/N2)^2 / N
* Sxy = Sxy1 + Sxy2 + N1 * N2 * (Sx1/N1 - Sx2/N2) * (Sy1/N1 - Sy2/N2) / N
*
* It's worth handling the special cases N1 = 0 and N2 = 0 separately
* since those cases are trivial, and we then don't need to worry about
* division-by-zero errors in the general case.
*--------------------
*/
if (N1 == 0.0)
{
N = N2;
Sx = Sx2;
Sxx = Sxx2;
Sy = Sy2;
Syy = Syy2;
Sxy = Sxy2;
}
else if (N2 == 0.0)
{
N = N1;
Sx = Sx1;
Sxx = Sxx1;
Sy = Sy1;
Syy = Syy1;
Sxy = Sxy1;
}
else
{
N = N1 + N2;
Sx = float8_pl(Sx1, Sx2);
tmp1 = Sx1 / N1 - Sx2 / N2;
Sxx = Sxx1 + Sxx2 + N1 * N2 * tmp1 * tmp1 / N;
check_float8_val(Sxx, isinf(Sxx1) || isinf(Sxx2), true);
Sy = float8_pl(Sy1, Sy2);
tmp2 = Sy1 / N1 - Sy2 / N2;
Syy = Syy1 + Syy2 + N1 * N2 * tmp2 * tmp2 / N;
check_float8_val(Syy, isinf(Syy1) || isinf(Syy2), true);
Sxy = Sxy1 + Sxy2 + N1 * N2 * tmp1 * tmp2 / N;
check_float8_val(Sxy, isinf(Sxy1) || isinf(Sxy2), true);
}
/*
* If we're invoked as an aggregate, we can cheat and modify our first
* parameter in-place to reduce palloc overhead. Otherwise we construct a
* new array with the updated transition data and return it.
*/
if (AggCheckCallContext(fcinfo, NULL))
{
transvalues1[0] = N;
transvalues1[1] = Sx;
transvalues1[2] = Sxx;
transvalues1[3] = Sy;
transvalues1[4] = Syy;
transvalues1[5] = Sxy;
PG_RETURN_ARRAYTYPE_P(transarray1);
}
else
{
Datum transdatums[6];
ArrayType *result;
transdatums[0] = Float8GetDatumFast(N);
transdatums[1] = Float8GetDatumFast(Sx);
transdatums[2] = Float8GetDatumFast(Sxx);
transdatums[3] = Float8GetDatumFast(Sy);
transdatums[4] = Float8GetDatumFast(Syy);
transdatums[5] = Float8GetDatumFast(Sxy);
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
result = construct_array(transdatums, 6,
FLOAT8OID,
sizeof(float8), FLOAT8PASSBYVAL, 'd');
PG_RETURN_ARRAYTYPE_P(result);
}
Add combine functions for various floating-point aggregates. This allows parallel aggregation to use them. It may seem surprising that we use float8_combine for both float4_accum and float8_accum transition functions, but that's because those functions differ only in the type of the non-transition-state argument. Haribabu Kommi, reviewed by David Rowley and Tomas Vondra
2016-04-08 19:44:50 +02:00
}
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
Datum
float8_regr_sxx(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_sxx", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx = transvalues[2];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxx);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_syy(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Syy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_syy", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Syy = transvalues[4];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Syy is guaranteed to be non-negative */
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Syy);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_sxy(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_sxy", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
/* A negative result is valid here */
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxy);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_avgx(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_avgx", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx = transvalues[1];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sx / N);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_avgy(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_avgy", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sy = transvalues[3];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sy / N);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_covar_pop(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_covar_pop", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxy / N);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_covar_samp(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_covar_samp", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is <= 1 we should return NULL */
if (N < 2.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxy / (N - 1.0));
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_corr(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx,
Syy,
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_corr", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx = transvalues[2];
Syy = transvalues[4];
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx and Syy are guaranteed to be non-negative */
/* per spec, return NULL for horizontal and vertical lines */
if (Sxx == 0 || Syy == 0)
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_NULL();
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxy / sqrt(Sxx * Syy));
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_r2(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx,
Syy,
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_r2", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx = transvalues[2];
Syy = transvalues[4];
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx and Syy are guaranteed to be non-negative */
/* per spec, return NULL for a vertical line */
if (Sxx == 0)
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* per spec, return 1.0 for a horizontal line */
if (Syy == 0)
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_FLOAT8(1.0);
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8((Sxy * Sxy) / (Sxx * Syy));
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_slope(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx,
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_slope", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sxx = transvalues[2];
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
/* per spec, return NULL for a vertical line */
if (Sxx == 0)
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_NULL();
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8(Sxy / Sxx);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Datum
float8_regr_intercept(PG_FUNCTION_ARGS)
{
ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
float8 *transvalues;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
float8 N,
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx,
Sxx,
Sy,
Sxy;
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
transvalues = check_float8_array(transarray, "float8_regr_intercept", 6);
N = transvalues[0];
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
Sx = transvalues[1];
Sxx = transvalues[2];
Sy = transvalues[3];
Sxy = transvalues[5];
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
/* if N is 0 we should return NULL */
if (N < 1.0)
PG_RETURN_NULL();
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
/* Note that Sxx is guaranteed to be non-negative */
/* per spec, return NULL for a vertical line */
if (Sxx == 0)
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
PG_RETURN_NULL();
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Improve the accuracy of floating point statistical aggregates. When computing statistical aggregates like variance, the common schoolbook algorithm which computes the sum of the squares of the values and subtracts the square of the mean can lead to a large loss of precision when using floating point arithmetic, because the difference between the two terms is often very small relative to the terms themselves. To avoid this, re-work these aggregates to use the Youngs-Cramer algorithm, which is a proven, numerically stable algorithm that directly aggregates the sum of the squares of the differences of the values from the mean in a single pass over the data. While at it, improve the test coverage to test the aggregate combine functions used during parallel aggregation. Per report and suggested algorithm from Erich Schubert. Patch by me, reviewed by Madeleine Thompson. Discussion: https://postgr.es/m/153313051300.1397.9594490737341194671@wrigleys.postgresql.org
2018-10-06 12:20:09 +02:00
PG_RETURN_FLOAT8((Sy - Sx * Sxy / Sxx) / N);
SQL2003-standard statistical aggregates, by Sergey Koposov. I've added only the float8 versions of the aggregates, which is all that the standard requires. Sergey's original patch also provided versions using numeric arithmetic, but given the size and slowness of the code, I doubt we ought to include those in core.
2006-07-28 20:33:04 +02:00
}
Revise aggregate functions per earlier discussions in pghackers. There's now only one transition value and transition function. NULL handling in aggregates is a lot cleaner. Also, use Numeric accumulators instead of integer accumulators for sum/avg on integer datatypes --- this avoids overflow at the cost of being a little slower. Implement VARIANCE() and STDDEV() aggregates in the standard backend. Also, enable new LIKE selectivity estimators by default. Unrelated change, but as long as I had to force initdb anyway...
2000-07-17 05:05:41 +02:00
/*
* ====================================
* MIXED-PRECISION ARITHMETIC OPERATORS
* ====================================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float48pl - returns arg1 + arg2
* float48mi - returns arg1 - arg2
* float48mul - returns arg1 * arg2
* float48div - returns arg1 / arg2
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48pl(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_pl((float8) arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48mi(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mi((float8) arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48mul(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mul((float8) arg1, arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48div(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_div((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float84pl - returns arg1 + arg2
* float84mi - returns arg1 - arg2
* float84mul - returns arg1 * arg2
* float84div - returns arg1 / arg2
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84pl(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_pl(arg1, (float8) arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84mi(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mi(arg1, (float8) arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84mul(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_mul(arg1, (float8) arg2));
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84div(PG_FUNCTION_ARGS)
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_FLOAT8(float8_div(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* ====================
* COMPARISON OPERATORS
* ====================
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
/*
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
* float48{eq,ne,lt,le,gt,ge} - float4/float8 comparison operations
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48eq(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_eq((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48ne(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_ne((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48lt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_lt((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48le(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_le((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48gt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_gt((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float48ge(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float4 arg1 = PG_GETARG_FLOAT4(0);
float8 arg2 = PG_GETARG_FLOAT8(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_ge((float8) arg1, arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
/*
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
* float84{eq,ne,lt,le,gt,ge} - float8/float4 comparison operations
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
*/
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84eq(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_eq(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84ne(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_ne(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84lt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_lt(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84le(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_le(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84gt(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_gt(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
Datum
float84ge(PG_FUNCTION_ARGS)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
float8 arg1 = PG_GETARG_FLOAT8(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Provide separate header file for built-in float types Some data types under adt/ have separate header files, but most simple ones do not, and their public functions are defined in builtins.h. As the patches improving geometric types will require making additional functions public, this seems like a good opportunity to create a header for floats types. Commit 1acf757255 made _cmp functions public to solve NaN issues locally for GiST indexes. This patch reworks it in favour of a more widely applicable API. The API uses inline functions, as they are easier to use compared to macros, and avoid double-evaluation hazards. Author: Emre Hasegeli Reviewed-by: Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
2018-07-29 03:30:48 +02:00
PG_RETURN_BOOL(float8_ge(arg1, (float8) arg2));
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
/*
* Implements the float8 version of the width_bucket() function
* defined by SQL2003. See also width_bucket_numeric().
*
* 'bound1' and 'bound2' are the lower and upper bounds of the
* histogram's range, respectively. 'count' is the number of buckets
* in the histogram. width_bucket() returns an integer indicating the
* bucket number that 'operand' belongs to in an equiwidth histogram
* with the specified characteristics. An operand smaller than the
* lower bound is assigned to bucket 0. An operand greater than the
* upper bound is assigned to an additional bucket (with number
* count+1). We don't allow "NaN" for any of the float8 inputs, and we
* don't allow either of the histogram bounds to be +/- infinity.
*/
Datum
width_bucket_float8(PG_FUNCTION_ARGS)
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
float8 operand = PG_GETARG_FLOAT8(0);
float8 bound1 = PG_GETARG_FLOAT8(1);
float8 bound2 = PG_GETARG_FLOAT8(2);
int32 count = PG_GETARG_INT32(3);
int32 result;
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
if (count <= 0.0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_WIDTH_BUCKET_FUNCTION),
errmsg("count must be greater than zero")));
if (isnan(operand) || isnan(bound1) || isnan(bound2))
ereport(ERROR,
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_WIDTH_BUCKET_FUNCTION),
Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
errmsg("operand, lower bound, and upper bound cannot be NaN")));
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
/* Note that we allow "operand" to be infinite */
Remove the special cases to prevent minus-zero results in float4 and float8 unary minus operators. We weren't attempting to prevent minus zero anywhere else; in view of our gradual trend to make the float datatypes more IEEE standard compliant, we should allow minus zero here rather than disallow it elsewhere. We don't, however, expect that all platforms will produce minus zero, so we need to adjust the one affected regression test to allow both results. Per discussion of bug #4660. (In passing, clean up a couple other minor infelicities in float.c.)
2009-02-18 20:23:26 +01:00
if (isinf(bound1) || isinf(bound2))
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_WIDTH_BUCKET_FUNCTION),
errmsg("lower and upper bounds must be finite")));
if (bound1 < bound2)
{
if (operand < bound1)
result = 0;
else if (operand >= bound2)
{
Use new overflow aware integer operations. A previous commit added inline functions that provide fast(er) and correct overflow checks for signed integer math. Use them in a significant portion of backend code. There's more to touch in both backend and frontend code, but these were the easily identifiable cases. The old overflow checks are noticeable in integer heavy workloads. A secondary benefit is that getting rid of overflow checks that rely on signed integer overflow wrapping around, will allow us to get rid of -fwrapv in the future. Which in turn slows down other code. Author: Andres Freund Discussion: https://postgr.es/m/20171024103954.ztmatprlglz3rwke@alap3.anarazel.de
2017-12-13 01:32:31 +01:00
if (pg_add_s32_overflow(count, 1, &result))
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("integer out of range")));
}
else
result = ((float8) count * (operand - bound1) / (bound2 - bound1)) + 1;
}
else if (bound1 > bound2)
{
if (operand > bound1)
result = 0;
else if (operand <= bound2)
{
Use new overflow aware integer operations. A previous commit added inline functions that provide fast(er) and correct overflow checks for signed integer math. Use them in a significant portion of backend code. There's more to touch in both backend and frontend code, but these were the easily identifiable cases. The old overflow checks are noticeable in integer heavy workloads. A secondary benefit is that getting rid of overflow checks that rely on signed integer overflow wrapping around, will allow us to get rid of -fwrapv in the future. Which in turn slows down other code. Author: Andres Freund Discussion: https://postgr.es/m/20171024103954.ztmatprlglz3rwke@alap3.anarazel.de
2017-12-13 01:32:31 +01:00
if (pg_add_s32_overflow(count, 1, &result))
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("integer out of range")));
}
else
result = ((float8) count * (bound1 - operand) / (bound1 - bound2)) + 1;
}
else
{
ereport(ERROR,
(errcode(ERRCODE_INVALID_ARGUMENT_FOR_WIDTH_BUCKET_FUNCTION),
errmsg("lower bound cannot equal upper bound")));
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
result = 0; /* keep the compiler quiet */
Implement width_bucket() for the float8 data type. The implementation is somewhat ugly logic-wise, but I don't see an easy way to make it more concise. When writing this, I noticed that my previous implementation of width_bucket() doesn't handle NaN correctly: postgres=# select width_bucket('NaN', 1, 5, 5); width_bucket -------------- 6 (1 row) AFAICS SQL:2003 does not define a NaN value, so it doesn't address how width_bucket() should behave here. The patch changes width_bucket() so that ereport(ERROR) is raised if NaN is specified for the operand or the lower or upper bounds to width_bucket(). For float8, NaN is disallowed for any of the floating-point inputs, and +/- infinity is disallowed for the histogram bounds (but allowed for the operand). Update docs and regression tests, bump the catversion.
2007-01-16 22:41:14 +01:00
}
PG_RETURN_INT32(result);
}
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
/* ========== PRIVATE ROUTINES ========== */
Convert NEED_{RINT,CBRT,ISINF} to HAVE_* in prepration for configure...
1997-01-24 19:17:37 +01:00
#ifndef HAVE_CBRT
Improve our private implementation of cbrt() to give results of the accuracy expected by the regression tests. Per suggestion from Martijn van Oosterhout.
2006-04-24 22:36:32 +02:00
Convert all remaining float4 and float8 functions to new fmgr style. At this point I think it'd be possible to make float4 be pass-by-value without too much work --- and float8 too on machines where Datum is 8 bytes. Something to try when the mood strikes, anyway.
2000-08-01 20:29:35 +02:00
static double
cbrt(double x)
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
{
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
1997-09-08 04:41:22 +02:00
int isneg = (x < 0.0);
Improve our private implementation of cbrt() to give results of the accuracy expected by the regression tests. Per suggestion from Martijn van Oosterhout.
2006-04-24 22:36:32 +02:00
double absx = fabs(x);
double tmpres = pow(absx, (double) 1.0 / (double) 3.0);
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* The result is somewhat inaccurate --- not really pow()'s fault, as the
* exponent it's handed contains roundoff error. We can improve the
* accuracy by doing one iteration of Newton's formula. Beware of zero
* input however.
Improve our private implementation of cbrt() to give results of the accuracy expected by the regression tests. Per suggestion from Martijn van Oosterhout.
2006-04-24 22:36:32 +02:00
*/
if (tmpres > 0.0)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
tmpres -= (tmpres - absx / (tmpres * tmpres)) / (double) 3.0;
Massive commit to run PGINDENT on all *.c and *.h files.
1997-09-07 07:04:48 +02:00
Renaming cleanup, no pgindent yet.
1998-09-01 05:29:17 +02:00
return isneg ? -tmpres : tmpres;
Postgres95 1.01 Distribution - Virgin Sources
1996-07-09 08:22:35 +02:00
}
Another pgindent run. Fixes enum indenting, and improves #endif spacing. Also adds space for one-line comments.
2001-10-28 07:26:15 +01:00
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* !HAVE_CBRT */