upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-03-17 16:12:13 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/include/utils/numeric.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

81 lines
2.6 KiB
C
Raw Normal View History

Reimplement NUMERIC datatype using base-10000 arithmetic; also improve some of the algorithms for higher functions. I see about a factor of ten speedup on the 'numeric' regression test, but it's unlikely that that test is representative of real-world applications. initdb forced due to change of on-disk representation for NUMERIC.
2003-03-20 20:58:05 -05:00
/*-------------------------------------------------------------------------
*
Change my-function-name-- to my_function_name, and optimizer renames.
1999-02-13 18:22:53 -05:00
* numeric.h
Reimplement NUMERIC datatype using base-10000 arithmetic; also improve some of the algorithms for higher functions. I see about a factor of ten speedup on the 'numeric' regression test, but it's unlikely that that test is representative of real-world applications. initdb forced due to change of on-disk representation for NUMERIC.
2003-03-20 20:58:05 -05:00
* Definitions for the exact numeric data type of Postgres
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
*
Reimplement NUMERIC datatype using base-10000 arithmetic; also improve some of the algorithms for higher functions. I see about a factor of ten speedup on the 'numeric' regression test, but it's unlikely that that test is representative of real-world applications. initdb forced due to change of on-disk representation for NUMERIC.
2003-03-20 20:58:05 -05:00
* Original coding 1998, Jan Wieck. Heavily revised 2003, Tom Lane.
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
*
Update copyright for 2021 Backpatch-through: 9.5
2021-01-02 13:06:25 -05:00
* Copyright (c) 1998-2021, PostgreSQL Global Development Group
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
*
Remove cvs keywords from all files.
2010-09-20 16:08:53 -04:00
* src/include/utils/numeric.h
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
*
Reimplement NUMERIC datatype using base-10000 arithmetic; also improve some of the algorithms for higher functions. I see about a factor of ten speedup on the 'numeric' regression test, but it's unlikely that that test is representative of real-world applications. initdb forced due to change of on-disk representation for NUMERIC.
2003-03-20 20:58:05 -05:00
*-------------------------------------------------------------------------
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
*/
#ifndef _PG_NUMERIC_H_
#define _PG_NUMERIC_H_
Allow each C include file to compile on its own by including any needed header files.
2006-07-11 09:54:25 -04:00
#include "fmgr.h"
Alter scale selection for NUMERIC division and transcendental functions so that precision of result is always at least as good as you'd get from float8 arithmetic (ie, always at least 16 digits of accuracy). Per pg_hackers discussion a few days ago.
2002-10-02 15:21:26 -04:00
/*
Remove bogus dependencies on NUMERIC_MAX_PRECISION. NUMERIC_MAX_PRECISION is a purely arbitrary constraint on the precision and scale you can write in a numeric typmod. It might once have had something to do with the allowed range of a typmod-less numeric value, but at least since 9.1 we've allowed, and documented that we allowed, any value that would physically fit in the numeric storage format; which is something over 100000 decimal digits, not 1000. Hence, get rid of numeric_in()'s use of NUMERIC_MAX_PRECISION as a limit on the allowed range of the exponent in scientific-format input. That was especially silly in view of the fact that you can enter larger numbers as long as you don't use 'e' to do it. Just constrain the value enough to avoid localized overflow, and let make_result be the final arbiter of what is too large. Likewise adjust ecpg's equivalent of this code. Also get rid of numeric_recv()'s use of NUMERIC_MAX_PRECISION to limit the number of base-NBASE digits it would accept. That created a dump/restore hazard for binary COPY without doing anything useful; the wire-format limit on number of digits (65535) is about as tight as we would want. In HEAD, also get rid of pg_size_bytes()'s unnecessary intimacy with what the numeric range limit is. That code doesn't exist in the back branches. Per gripe from Aravind Kumar. Back-patch to all supported branches, since they all contain the documentation claim about allowed range of NUMERIC (cf commit cabf5d84b). Discussion: <2895.1471195721@sss.pgh.pa.us>
2016-08-14 15:06:01 -04:00
* Limit on the precision (and hence scale) specifiable in a NUMERIC typmod.
* Note that the implementation limit on the length of a numeric value is
* much larger --- beware of what you use this for!
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
*/
Restricted maximum precision for NUMERIC to 1000 digits. Anything else is CPU overkill. Jan
1999-01-05 06:12:11 -05:00
#define NUMERIC_MAX_PRECISION 1000
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
Alter scale selection for NUMERIC division and transcendental functions so that precision of result is always at least as good as you'd get from float8 arithmetic (ie, always at least 16 digits of accuracy). Per pg_hackers discussion a few days ago.
2002-10-02 15:21:26 -04:00
/*
Clean up problems with rounding/overflow code in NUMERIC, particularly the case wherein zero was rejected for a field like NUMERIC(4,4). Miscellaneous other code beautification efforts.
2000-01-15 18:42:49 -05:00
* Internal limits on the scales chosen for calculation results
*/
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
#define NUMERIC_MAX_DISPLAY_SCALE NUMERIC_MAX_PRECISION
Alter scale selection for NUMERIC division and transcendental functions so that precision of result is always at least as good as you'd get from float8 arithmetic (ie, always at least 16 digits of accuracy). Per pg_hackers discussion a few days ago.
2002-10-02 15:21:26 -04:00
#define NUMERIC_MIN_DISPLAY_SCALE 0
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
Little precision fix for POWER(). I discovered problems with big exponents. Jan
1998-12-30 15:46:06 -05:00
#define NUMERIC_MAX_RESULT_SCALE (NUMERIC_MAX_PRECISION * 2)
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
Alter scale selection for NUMERIC division and transcendental functions so that precision of result is always at least as good as you'd get from float8 arithmetic (ie, always at least 16 digits of accuracy). Per pg_hackers discussion a few days ago.
2002-10-02 15:21:26 -04:00
/*
* For inherently inexact calculations such as division and square root,
* we try to get at least this many significant digits; the idea is to
* deliver a result no worse than float8 would.
*/
#define NUMERIC_MIN_SIG_DIGITS 16
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
Make details of the Numeric representation private to numeric.c. Review by Tom Lane.
2010-07-30 00:30:23 -04:00
/* The actual contents of Numeric are private to numeric.c */
struct NumericData;
typedef struct NumericData *Numeric;
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05: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 03:35:40 -04:00
/*
* fmgr interface macros
*/
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-16 23:05:41 -04:00
#define DatumGetNumeric(X) ((Numeric) PG_DETOAST_DATUM(X))
#define DatumGetNumericCopy(X) ((Numeric) PG_DETOAST_DATUM_COPY(X))
#define NumericGetDatum(X) PointerGetDatum(X)
#define PG_GETARG_NUMERIC(n) DatumGetNumeric(PG_GETARG_DATUM(n))
#define PG_GETARG_NUMERIC_COPY(n) DatumGetNumericCopy(PG_GETARG_DATUM(n))
#define PG_RETURN_NUMERIC(x) return NumericGetDatum(x)
Another pgindent run. Fixes enum indenting, and improves #endif spacing. Also adds space for one-line comments.
2001-10-28 01:26:15 -05:00
Support EEEE (scientific notation) in to_char(). Pavel Stehule, Brendan Jurd
2009-08-10 14:29:27 -04:00
/*
* Utility functions in numeric.c
*/
Make details of the Numeric representation private to numeric.c. Review by Tom Lane.
2010-07-30 00:30:23 -04:00
extern bool numeric_is_nan(Numeric num);
Support infinity and -infinity in the numeric data type. Add infinities that behave the same as they do in the floating-point data types. Aside from any intrinsic usefulness these may have, this closes an important gap in our ability to convert floating values to numeric and/or replace float-based APIs with numeric. The new values are represented by bit patterns that were formerly not used (although old code probably would take them for NaNs). So there shouldn't be any pg_upgrade hazard. Patch by me, reviewed by Dean Rasheed and Andrew Gierth Discussion: https://postgr.es/m/606717.1591924582@sss.pgh.pa.us
2020-07-22 19:19:44 -04:00
extern bool numeric_is_inf(Numeric num);
Fix declared argument name for numeric_maximum_size. The previous commit changed the function to say 'typmod' rather than 'typemod', but I forgot to update the header file.
2010-08-04 13:35:59 -04:00
int32 numeric_maximum_size(int32 typmod);
Support EEEE (scientific notation) in to_char(). Pavel Stehule, Brendan Jurd
2009-08-10 14:29:27 -04:00
extern char *numeric_out_sci(Numeric num, int scale);
Introduce jsonb, a structured format for storing json. The new format accepts exactly the same data as the json type. However, it is stored in a format that does not require reparsing the orgiginal text in order to process it, making it much more suitable for indexing and other operations. Insignificant whitespace is discarded, and the order of object keys is not preserved. Neither are duplicate object keys kept - the later value for a given key is the only one stored. The new type has all the functions and operators that the json type has, with the exception of the json generation functions (to_json, json_agg etc.) and with identical semantics. In addition, there are operator classes for hash and btree indexing, and two classes for GIN indexing, that have no equivalent in the json type. This feature grew out of previous work by Oleg Bartunov and Teodor Sigaev, which was intended to provide similar facilities to a nested hstore type, but which in the end proved to have some significant compatibility issues. Authors: Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan. Review: Andres Freund
2014-03-23 16:40:19 -04:00
extern char *numeric_normalize(Numeric num);
Support EEEE (scientific notation) in to_char(). Pavel Stehule, Brendan Jurd
2009-08-10 14:29:27 -04:00
Expose internal function for converting int64 to numeric Existing callers had to take complicated detours via DirectFunctionCall1(). This simplifies a lot of code. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-09-09 14:16:28 -04:00
extern Numeric int64_to_numeric(int64 val);
Change return type of EXTRACT to numeric The previous implementation of EXTRACT mapped internally to date_part(), which returned type double precision (since it was implemented long before the numeric type existed). This can lead to imprecise output in some cases, so returning numeric would be preferrable. Changing the return type of an existing function is a bit risky, so instead we do the following: We implement a new set of functions, which are now called "extract", in parallel to the existing date_part functions. They work the same way internally but use numeric instead of float8. The EXTRACT construct is now mapped by the parser to these new extract functions. That way, dumps of views etc. from old versions (which would use date_part) continue to work unchanged, but new uses will map to the new extract functions. Additionally, the reverse compilation of EXTRACT now reproduces the original syntax, using the new mechanism introduced in 40c24bfef92530bd846e111c1742c2a54441c62c. The following minor changes of behavior result from the new implementation: - The column name from an isolated EXTRACT call is now "extract" instead of "date_part". - Extract from date now rejects inappropriate field names such as HOUR. It was previously mapped internally to extract from timestamp, so it would silently accept everything appropriate for timestamp. - Return values when extracting fields with possibly fractional values, such as second and epoch, now have the full scale that the value has internally (so, for example, '1.000000' instead of just '1'). Reported-by: Petr Fedorov <petr.fedorov@phystech.edu> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 01:17:13 -04:00
extern Numeric int64_div_fast_to_numeric(int64 val1, int log10val2);
Expose internal function for converting int64 to numeric Existing callers had to take complicated detours via DirectFunctionCall1(). This simplifies a lot of code. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2020-09-09 14:16:28 -04: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 05:21:19 -04:00
extern Numeric numeric_add_opt_error(Numeric num1, Numeric num2,
bool *have_error);
extern Numeric numeric_sub_opt_error(Numeric num1, Numeric num2,
bool *have_error);
extern Numeric numeric_mul_opt_error(Numeric num1, Numeric num2,
bool *have_error);
extern Numeric numeric_div_opt_error(Numeric num1, Numeric num2,
bool *have_error);
extern Numeric numeric_mod_opt_error(Numeric num1, Numeric num2,
bool *have_error);
extern int32 numeric_int4_opt_error(Numeric num, bool *error);
Added NUMERIC data type with many builtin funcitons, operators and aggregates. Jan
1998-12-30 14:56:35 -05:00
#endif /* _PG_NUMERIC_H_ */
Reference in a new issue Copy permalink