Skip to content

Commit 26b6d48

Browse files
Make default numeric scale 9 (#86)
To give the integral part more room, we decided to make the default scale = 9 when the user does not specify precision and scale for numeric type. Multiplication of 2 numeric doubles the result scale and gives the integral part less digits. It is wiser to make it smaller but still useful number.
1 parent acfd42c commit 26b6d48

File tree

3 files changed

+4
-4
lines changed

3 files changed

+4
-4
lines changed

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -239,7 +239,7 @@ There is currently only one GUC parameter to enable/disable the `pg_parquet`:
239239
> * `numeric(9 < P <= 18, S)` is represented as `INT64` with `DECIMAL` logical type
240240
> * `numeric(18 < P <= 38, S)` is represented as `FIXED_LEN_BYTE_ARRAY(9-16)` with `DECIMAL` logical type
241241
> * `numeric(38 < P, S)` is represented as `BYTE_ARRAY` with `STRING` logical type
242-
> * `numeric` is allowed by Postgres. (precision and scale not specified). These are represented by a default precision (38) and scale (16) instead of writing them as string. You get runtime error if your table tries to read or write a numeric value which is not allowed by the default precision and scale (22 integral digits before decimal point, 16 digits after decimal point).
242+
> * `numeric` is allowed by Postgres. (precision and scale not specified). These are represented by a default precision (38) and scale (9) instead of writing them as string. You get runtime error if your table tries to read or write a numeric value which is not allowed by the default precision and scale (29 integral digits before decimal point, 9 digits after decimal point).
243243
> - (2) The `date` type is represented according to `Unix epoch` when writing to Parquet files. It is converted back according to `PostgreSQL epoch` when reading from Parquet files.
244244
> - (3) The `timestamptz` and `timetz` types are adjusted to `UTC` when writing to Parquet files. They are converted back with `UTC` timezone when reading from Parquet files.
245245
> - (4) The `geometry` type is represented as `BYTE_ARRAY` encoded as `WKB` when `postgis` extension is created. Otherwise, it is represented as `BYTE_ARRAY` with `STRING` logical type.

src/pgrx_tests/copy_type_roundtrip.rs

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -863,7 +863,7 @@ mod tests {
863863

864864
#[pg_test]
865865
#[should_panic(
866-
expected = "numeric value contains 23 digits before decimal point, which exceeds max allowed integral digits 22 during copy to parquet"
866+
expected = "numeric value contains 30 digits before decimal point, which exceeds max allowed integral digits 29 during copy to parquet"
867867
)]
868868
fn test_invalid_unbounded_numeric_integral_digits() {
869869
let invalid_integral_digits =
@@ -879,7 +879,7 @@ mod tests {
879879

880880
#[pg_test]
881881
#[should_panic(
882-
expected = "numeric value contains 17 digits after decimal point, which exceeds max allowed decimal digits 16 during copy to parquet"
882+
expected = "numeric value contains 10 digits after decimal point, which exceeds max allowed decimal digits 9 during copy to parquet"
883883
)]
884884
fn test_invalid_unbounded_numeric_decimal_digits() {
885885
let invalid_decimal_digits = DEFAULT_UNBOUNDED_NUMERIC_SCALE + 1;

src/type_compat/pg_arrow_type_conversions.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -277,7 +277,7 @@ fn rescale_unbounded_numeric_or_error(
277277

278278
const MAX_NUMERIC_PRECISION: u32 = 38;
279279
pub(crate) const DEFAULT_UNBOUNDED_NUMERIC_PRECISION: u32 = MAX_NUMERIC_PRECISION;
280-
pub(crate) const DEFAULT_UNBOUNDED_NUMERIC_SCALE: u32 = 16;
280+
pub(crate) const DEFAULT_UNBOUNDED_NUMERIC_SCALE: u32 = 9;
281281
pub(crate) const DEFAULT_UNBOUNDED_NUMERIC_MAX_INTEGRAL_DIGITS: u32 =
282282
DEFAULT_UNBOUNDED_NUMERIC_PRECISION - DEFAULT_UNBOUNDED_NUMERIC_SCALE;
283283

0 commit comments

Comments
 (0)