Re: [DISCUSS][MATLAB] Proposal for incremental point releases of the MATLAB interface

Hi, > One open question about this approach: which GitHub > repository should we use for hosting the MLTBX via GitHub > Releases? > > We don't think using the main apache/arrow GitHub Releases > area is the right approach. So, would it make sense to > create a separate "bridge" repository just fo

Re: [VOTE][RUST] Release Apache Arrow Rust 48.0.1 RC1

+1 (binding) Verified on x86_64 GNU/Linux On 09/11/2023 20:31, Andrew Lamb wrote: As discussed on [5], I would like to propose a patch release of Apache Arrow Rust Implementation, version 48.0.1 to include two bug fixes. This release candidate is based on commit: b60fc7bb09ada1385d3542b784fff2

Re: [VOTE][RUST] Release Apache Arrow Rust 48.0.1 RC1

+1 (binding) Verification script passed on Intel Mac. Thanks Andrew. On Thu, Nov 9, 2023 at 12:32 PM Andrew Lamb wrote: > > As discussed on [5], I would like to propose a patch release of Apache > Arrow Rust Implementation, version 48.0.1 to include two bug fixes. > > This release candidate is

Re: [VOTE][RUST] Release Apache Arrow Rust 49.0.0 RC1

+1 (binding) on Mac x86 Thank you Raphael Andrew On Thu, Nov 9, 2023 at 11:49 AM Chao Sun wrote: > +1 (non-binding) > > Verified on M1 Mac. Thanks Raphael. > > On Thu, Nov 9, 2023 at 12:47 AM Wayne Xia wrote: > > > > +1 (non-binding) > > > > Verified on Intel Linux > > > > Thanks Raphael > >

[VOTE][RUST] Release Apache Arrow Rust 48.0.1 RC1

As discussed on [5], I would like to propose a patch release of Apache Arrow Rust Implementation, version 48.0.1 to include two bug fixes. This release candidate is based on commit: b60fc7bb09ada1385d3542b784fff2915fbc9cff [1] The proposed release tarball and signatures are hosted at [2]. The ch

Re: decimal64

I think this should be a type. [1] is the last discussion on deciding, and I think the consensus was that if it is an additional parameterization of existing types, then using the existing type makes sense instead of an extension type. [1] https://lists.apache.org/thread/3nls3222ggnxlrp0s46rxrcmg

Re: decimal64

> Sidenote: I haven't seen many proposals for canonical extension types > until now, which is a bit surprising. The barrier for standardizing a > canonical extension type is much lower than for a new Arrow data type. Chiming in here, since I've done some exploration implementing bfloat16 as an ext

Re: decimal64

I would say no, because first-class float16 semantics are more easily provided on first-class data type. Regards Antoine. Le 09/11/2023 à 18:38, Curt Hagenlocher a écrit : It certainly could be. Would float16 be done as a canonical extension type if it were proposed today? On Thu, Nov 9,

Re: decimal64

If we want to provide useful arithmetic and conversions, then full-blown decimal64 (and perhaps decimal32) is warranted. If we want to easily expose and roundtrip PostgreSQL's fixed-scale money type with full binary precision, then I agree a canonical extension type is the way. And we can

Re: decimal64

It certainly could be. Would float16 be done as a canonical extension type if it were proposed today? On Thu, Nov 9, 2023 at 9:36 AM David Li wrote: > cuDF has decimal32/decimal64 [1]. > > Would a canonical extension type [2] be appropriate here? I think that's > come up as a solution before. >

Re: decimal64

cuDF has decimal32/decimal64 [1]. Would a canonical extension type [2] be appropriate here? I think that's come up as a solution before. [1]: https://docs.rapids.ai/api/cudf/stable/user_guide/data-types/ [2]: https://arrow.apache.org/docs/format/CanonicalExtensions.html On Thu, Nov 9, 2023, at

Re: decimal64

Or they could trivially use a int64 column for that, since the scale is fixed anyway, and you're probably not going to multiply money values together. Le 09/11/2023 à 17:54, Curt Hagenlocher a écrit : If Arrow had a decimal64 type, someone could choose to use that for a PostgreSQL money co

Re: decimal64

Narrower Decimal types has come up in the past as something that is desirable (for instance parquet supports using ints of similar precision/scale). IIRC I think the main blocker has been people willing to work on two compatible implementations. FWIW, we decided for Decimal256 to be conservative

Re: decimal64

If Arrow had a decimal64 type, someone could choose to use that for a PostgreSQL money column knowing that there are edge cases where they may get an undesired result. On Thu, Nov 9, 2023 at 8:42 AM Antoine Pitrou wrote: > > Le 09/11/2023 à 17:23, Curt Hagenlocher a écrit : > > Or more succinctl

Re: [VOTE][RUST] Release Apache Arrow Rust 49.0.0 RC1

+1 (non-binding) Verified on M1 Mac. Thanks Raphael. On Thu, Nov 9, 2023 at 12:47 AM Wayne Xia wrote: > > +1 (non-binding) > > Verified on Intel Linux > > Thanks Raphael > > On Wed, Nov 8, 2023 at 6:12 AM L. C. Hsieh wrote: > > > +1 (binding) > > > > Verified on Intel Mac. > > > > Thanks Raphae

Re: decimal64

Le 09/11/2023 à 17:23, Curt Hagenlocher a écrit : Or more succinctly, "111,111,111,111,111." will fit into a decimal64; would you prevent it from being stored in one so that you can describe the column as "decimal(18, 4)"? That's what we do for other decimal types, see PyArrow below: ```

Re: decimal64

(But yes, I think this would be more commonly described as having a precision of 18 and my writeup was probably influenced by looking at the SQL Server and Postgres descriptions of the "money" type, both of which allow the full range of the underlying 64-bit value to be used.) On Thu, Nov 9, 2023

Re: decimal64

Obviously the limits don't match up exactly, so it depends on whether you want to express the decimal bounds in a way that captures all the possible underlying values or in a way that allows all the decimal values to be represented as the underlying type. Or more succinctly, "111,111,111,111,111.11

Re: decimal64

Perhaps my maths is incorrect, but a decimal64 would have a maximum precision of 18, not 19? log(9223372036854775807) = 18.9? On 09/11/2023 16:01, Curt Hagenlocher wrote: Recently, someone opened an issue on GitHub ([C++] Decimal64/32 support? · Issue #38622 · apache/arrow (github.com)

decimal64

Recently, someone opened an issue on GitHub ([C++] Decimal64/32 support? · Issue #38622 · apache/arrow (github.com) ) asking for support for narrower decimal types. They were advised to start a thread on the mailing list, and as they haven't done so yet

[ANNOUNCE] Apache Arrow ADBC 0.8.0 released

The Apache Arrow community is pleased to announce the 0.8.0 release of the Apache Arrow ADBC libraries. It includes 43 resolved GitHub issues ([1]). The release is available now from [2] and [3]. Release notes are available at: https://github.com/apache/arrow-adbc/blob/apache-arrow-adbc-0.8.0/C

[RESULT][VOTE] Release Apache Arrow ADBC 0.8.0 - RC0

Re-sending with RESULT [x] Close the GitHub milestone/project [x] Add the new release to the Apache Reporter System [x] Upload source release artifacts to Subversion [x] Create the final GitHub release [x] Update website [x] Upload wheels/sdist to PyPI [x] Publish Maven packages [x] Update tags fo

Re: [DataFusion] Introduce qualified alias expressions

Thank you for raising this Marko -- for anyone else following along there is some great discussion on the ticket and I would encourage anyone who is interested to share your thoughts there as well. On Wed, Nov 8, 2023 at 7:24 PM Jeremy Dyer wrote: > From an Arrow Datafusion Python consumer stand

[DISCUSS] arrow-rs 48.0.1 patch release

For various reasons, I plan to make an arrow-rs patch release with bug fixes. Please comment on the ticket[1] if you have any thoughts or other suggestions of what to include. Andrew [1] https://github.com/apache/arrow-rs/issues/5050

Re: [VOTE][FORMAT] Bulk ingestion support for Flight SQL

For the record, the correct PR link seems to be https://github.com/apache/arrow/pull/38385 Le 08/11/2023 à 21:49, David Li a écrit : Hello, Joel Lubi has proposed adding bulk ingestion support to Arrow Flight SQL [1]. This provides a path for uploading an Arrow dataset to a Flight SQL ser

Re: [VOTE][RUST] Release Apache Arrow Rust 49.0.0 RC1

+1 (non-binding) Verified on Intel Linux Thanks Raphael On Wed, Nov 8, 2023 at 6:12 AM L. C. Hsieh wrote: > +1 (binding) > > Verified on Intel Mac. > > Thanks Raphael. > > On Tue, Nov 7, 2023 at 1:38 PM Andy Grove wrote: > > > > +1 (binding) > > > > Verified on Ubuntu 22.04.3 LTS. > > > > Tha