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
40c24bfef9.

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

src/backend/utils/adt/numeric.c

@@ -4092,6 +4092,67 @@ int64_to_numeric(int64 val)
 	return res;
 }
 
+/*
+ * Convert val1/(10**val2) to numeric.  This is much faster than normal
+ * numeric division.
+ */
+Numeric
+int64_div_fast_to_numeric(int64 val1, int log10val2)
+{
+	Numeric		res;
+	NumericVar	result;
+	int64		saved_val1 = val1;
+	int			w;
+	int			m;
+
+	/* how much to decrease the weight by */
+	w = log10val2 / DEC_DIGITS;
+	/* how much is left */
+	m = log10val2 % DEC_DIGITS;
+
+	/*
+	 * If there is anything left, multiply the dividend by what's left, then
+	 * shift the weight by one more.
+	 */
+	if (m > 0)
+	{
+		static int	pow10[] = {1, 10, 100, 1000};
+
+		StaticAssertStmt(lengthof(pow10) == DEC_DIGITS, "mismatch with DEC_DIGITS");
+		if (unlikely(pg_mul_s64_overflow(val1, pow10[DEC_DIGITS - m], &val1)))
+		{
+			/*
+			 * If it doesn't fit, do the whole computation in numeric the slow
+			 * way.  Note that va1l may have been overwritten, so use
+			 * saved_val1 instead.
+			 */
+			int			val2 = 1;
+
+			for (int i = 0; i < log10val2; i++)
+				val2 *= 10;
+			res = numeric_div_opt_error(int64_to_numeric(saved_val1), int64_to_numeric(val2), NULL);
+			res = DatumGetNumeric(DirectFunctionCall2(numeric_round,
+													  NumericGetDatum(res),
+													  Int32GetDatum(log10val2)));
+			return res;
+		}
+		w++;
+	}
+
+	init_var(&result);
+
+	int64_to_numericvar(val1, &result);
+
+	result.weight -= w;
+	result.dscale += w * DEC_DIGITS - (DEC_DIGITS - m);
+
+	res = make_result(&result);
+
+	free_var(&result);
+
+	return res;
+}
+
 Datum
 int4_numeric(PG_FUNCTION_ARGS)
 {