Re: [VOTE] Spec Update: Variant Field Lower/Upper Bounds

+1 (non binding) Regards JB On Fri, Apr 18, 2025 at 5:25 AM Aihua Xu wrote: > > Hi all, > > I'd like to initiate a vote to include a spec update for supporting lower and > upper bounds on Variant fields. Summary of the change: > > The writer determines which fields to collect bounds for a Varia

Re: [VOTE] Small spec change for default values

+1 (non binding) Regards JB On Mon, Apr 21, 2025 at 11:20 PM Ryan Blue wrote: > > Hi everyone, > > I’d like to vote on the spec changes in PR 12841. This is a small change that > makes handling default values for structs much easier. Initially, we allowed > both a struct and its fields to have

Re: [DISCUSS] Release 1.8.2?

Hi Manu It's exactly what I said in the 1.9.0 thread and I agree with Fokko. I don't think it would make sense to release 1.8.2 with the message about the CVE (I agree if it's to fix other things, but it doesn't seem to be the case). We can "confuse" the users with 1.8.2 release related to CVE bu

[DISCUSS] Release 1.8.2?

Hi all, I thought we had a consensus on releasing 1.8.2 and volunteered to be the release manager following these discussions[1][2]. However, when working with Fokko to make a release, he expressed concerns over the release. Let me quote his words here. I did some checks, and it looks like the vu

Re: [VOTE] Small spec change for default values

+1 to the direction (non-binding). Left some clarification comments on the PR. Thanks, Walaa. On Mon, Apr 21, 2025 at 10:57 PM Manu Zhang wrote: > +1 (non-binding) except for some ambiguity between struct field and fields > within struct (Russell already made a nice suggestion). > > Thanks, >

Re: [VOTE] Small spec change for default values

+1 (non-binding) except for some ambiguity between struct field and fields within struct (Russell already made a nice suggestion). Thanks, Manu On Tue, Apr 22, 2025 at 7:10 AM Amogh Jahagirdar <2am...@gmail.com> wrote: > +1 (binding) > > On Mon, Apr 21, 2025 at 3:38 PM Russell Spitzer > wrote:

Discuss proposal - IRC APIs for Multi-Statement Multi-Table Transactions

Hi Iceberg dev community, cc: Dru - I have been collaborating with him. I want to start this email thread to discuss an IRC API proposal to enable engines to implement Multi-Statement Multi-Table Transactions. More details in the document: https://docs.google.com/document/d/1jr4Ah8oceOmo6fwxG_0I

Re: [VOTE] Small spec change for default values

+1 (binding) On Mon, Apr 21, 2025 at 3:38 PM Russell Spitzer wrote: > +1 (Binding) > > On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue wrote: > >> Hi everyone, >> >> I’d like to vote on the spec changes in PR 12841 >> . This is a small change >> that make

Re: [VOTE] Small spec change for default values

+1 (Binding) On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue wrote: > Hi everyone, > > I’d like to vote on the spec changes in PR 12841 > . This is a small change > that makes handling default values for structs much easier. Initially, we > allowed both a

[VOTE] Small spec change for default values

Hi everyone, I’d like to vote on the spec changes in PR 12841 . This is a small change that makes handling default values for structs much easier. Initially, we allowed both a struct and its fields to have default values, but the values could conflict.

Re: [VOTE] Spec Update: Variant Field Lower/Upper Bounds

This passes with 13 votes (+6 bindings and +7 non-bindings) and no -1 or +0 votes. Thanks everyone! On Mon, Apr 21, 2025 at 1:26 PM Aihua Xu wrote: > +1 (non-binding) from me. > > On Sun, Apr 20, 2025 at 12:19 PM Denny Lee wrote: > >> +1 (non-binding) >> >> On Sun, Apr 20, 2025 at 11:22 Fokko

Re: [VOTE] Spec Update: Variant Field Lower/Upper Bounds

+1 (non-binding) from me. On Sun, Apr 20, 2025 at 12:19 PM Denny Lee wrote: > +1 (non-binding) > > On Sun, Apr 20, 2025 at 11:22 Fokko Driesprong wrote: > >> +1 (binding) >> >> Op zo 20 apr 2025 om 05:59 schreef Daniel Weeks : >> >>> +1 (binding) >>> >>> On Sat, Apr 19, 2025, 12:07 AM Gang Wu

Re: Iceberg Interval Types Proposal

I think this is a pretty good idea for us to adopt in terms of compatibility with other systems and I really appreciate that Naren made sure to use a broad enough definition to support all available engines. I'm really interested to know how other folks feel about this proposal and I hope we can re

Iceberg Interval Types Proposal

Dear Community, I want to propose the addition of the Interval types to the Iceberg spec. A value of an Interval type represents a duration of time, and can be calculated by the difference between two dates or times. Intervals are supported across a variety of different engines (e.g. Parquet, Spar

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Thanks Renjie! The existing spec has some guidance on resolving catalogs on the fly already (to address the case of view text with table identifiers missing the catalog part). The guidance is to use the catalog where the view is stored. But I find this rule hard to interpret or use. The catalog it