GH-44569: [GLib] Add GArrowDecimal64DataType

[hiroyuki-sato]

Rationale for this change

arrow::Decimal64Type data type has been introduced. It is also necessary to support the same data type in GLib.

What changes are included in this PR?

This PR implements GArrowDecimal64DataType.

Are these changes tested?

YES

Are there any user-facing changes?

Before this change: Arrow::DecimalDataType.new(8, 2) returned Decimal128DataType.
After this change: Arrow::DecimalDataType.new(8, 2) returns Decimal64DataType

• GitHub Issue: [GLib] Add GArrowDecimal64DataType #44569

[github-actions]

⚠️ GitHub issue #44569 has been automatically assigned in GitHub to PR creator.

[kou]

Could you use the same order as arrow::Type::type? We want to use the same values as arrow::Type::type:

arrow/c_glib/arrow-glib/type.h

Line 74 in 2df7b23

* They are corresponding to `arrow::Type::type` values.

We can use = 44 for now:

arrow/cpp/src/arrow/type_fwd.h

Lines 464 to 465 in 2df7b23

	/// Precision- and scale-based decimal type with 64 bits.
	DECIMAL64 = 44,

diff --git a/c_glib/arrow-glib/type.h b/c_glib/arrow-glib/type.h
index 6f33ad64ef..9c2843109e 100644
--- a/c_glib/arrow-glib/type.h
+++ b/c_glib/arrow-glib/type.h
@@ -113,6 +113,8 @@ typedef enum {
   GARROW_TYPE_LARGE_LIST,
   GARROW_TYPE_MONTH_DAY_NANO_INTERVAL,
   GARROW_TYPE_RUN_END_ENCODED,
+  /* TODO: Remove = 44 when we add STRING_VIEW..DECIMAL32. */
+  GARROW_TYPE_DECIMAL64 = 44,
 } GArrowType;
 
 /**

[hiroyuki-sato]

Thanks Fixed. What does STRING_VIEW mean by the way?

[kou]

https://arrow.apache.org/docs/format/Columnar.html#variable-size-binary-view-layout

We should support it in GLib too.

[kou]

Could you use the same order as the definition? (Could you move this to after the @GARROW_TYPE_RUN_END_ENCODED?)

[hiroyuki-sato]

I changed the order in 8217b31

[mapleFU]

Just a naive problem, why decimal32 not implemented? Just first not involve it in this pull request?

[kou]

Right. We'll work on decimal32 in a separated PR.
#44392

[kou]

+1

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 4c36f12.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 2 possible false positives for unstable benchmarks that are known to sometimes produce them.