postgresql/src/include/utils/numeric.h

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

106 lines
3.1 KiB
C
Raw Normal View History

/*-------------------------------------------------------------------------
*
* numeric.h
* Definitions for the exact numeric data type of Postgres
*
* Original coding 1998, Jan Wieck. Heavily revised 2003, Tom Lane.
*
* Copyright (c) 1998-2023, PostgreSQL Global Development Group
*
2010-09-20 16:08:53 -04:00
* src/include/utils/numeric.h
*
*-------------------------------------------------------------------------
*/
#ifndef _PG_NUMERIC_H_
#define _PG_NUMERIC_H_
#include "fmgr.h"
/*
* Limits on the precision and scale specifiable in a NUMERIC typmod. The
* precision is strictly positive, but the scale may be positive or negative.
* A negative scale implies rounding before the decimal point.
*
* Note that the minimum display scale defined below is zero --- we always
* display all digits before the decimal point, even when the scale is
* negative.
*
* Note that the implementation limits on the precision and display scale of a
* numeric value are much larger --- beware of what you use these for!
*/
#define NUMERIC_MAX_PRECISION 1000
#define NUMERIC_MIN_SCALE (-1000)
#define NUMERIC_MAX_SCALE 1000
/*
* Internal limits on the scales chosen for calculation results
*/
#define NUMERIC_MAX_DISPLAY_SCALE NUMERIC_MAX_PRECISION
#define NUMERIC_MIN_DISPLAY_SCALE 0
#define NUMERIC_MAX_RESULT_SCALE (NUMERIC_MAX_PRECISION * 2)
/*
* 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
/* The actual contents of Numeric are private to numeric.c */
struct NumericData;
typedef struct NumericData *Numeric;
/*
* fmgr interface macros
*/
static inline Numeric
DatumGetNumeric(Datum X)
{
return (Numeric) PG_DETOAST_DATUM(X);
}
static inline Numeric
DatumGetNumericCopy(Datum X)
{
return (Numeric) PG_DETOAST_DATUM_COPY(X);
}
static inline Datum
NumericGetDatum(Numeric X)
{
return 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)
/*
* Utility functions in numeric.c
*/
extern bool numeric_is_nan(Numeric num);
extern bool numeric_is_inf(Numeric num);
extern int32 numeric_maximum_size(int32 typmod);
extern char *numeric_out_sci(Numeric num, int scale);
extern char *numeric_normalize(Numeric num);
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);
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 *have_error);
#endif /* _PG_NUMERIC_H_ */