Re: [VOTE] Adopt the v2 spec changes

> adopt the pending v2 spec changes as the supported v2 spec I assume this vote wants to reach the consistency between the community members that we won't introduce any breaking changes in v2 spec, not discuss exposing v2 to SQL tables like the following, right ? CREATE TABLE prod.db.sample (

Re: [DISCUSS] Moving to apache-iceberg Slack workspace

Any updates on this? Given the fact of the currently broken invitation link, I think we should move asap. -Jack Ye On Tue, Jul 27, 2021 at 2:15 AM Piotr Findeisen wrote: > Hi, > > I don't have opinion which Slack workspace this is in, as long as it's > easy to join. > Manual joining process is

Re: [VOTE] Adopt the v2 spec changes

(non-binding) +1, this looks like a clean cut to me. We have been testing v2 internally for quite a while now, hopefully it can become the new default version soon to enable row level delete and update. -Jack Ye On Tue, Jul 27, 2021 at 9:59 AM Ryan Blue wrote: > I’d like to propose that we ado

Re: [DISCUSS] UUID type

Yes I agree with Jacques that fixed binary is what it is in the end. I think It is more about user experience, whether the conversion is done at the user side or Iceberg and engine side. Many people just store UUID as a 36 byte string instead of a 16 byte binary, so with an explicit UUID type, Iceb

Re: [DISCUSS] UUID type

What specific arguments are there for it being a first class type besides it is elsewhere? Is there some kind of optimization iceberg or an engine could do if it was typed versus just a bucket of bits? Fixed width binary seems to cover the cases I see in terms of actual functionality in the iceberg

Re: [DISCUSS] UUID type

One conversation I used to come across regarding UUID deprecation was from https://github.com/apache/iceberg/pull/1611 Thanks, Yan On Tue, Jul 27, 2021 at 1:07 PM Peter Vary wrote: > Hi Joshua, > > I do not have a strong preference about the UUID type, but I would like > the highlight, that the

Re: [DISCUSS] UUID type

Hi Joshua, I do not have a strong preference about the UUID type, but I would like the highlight, that the type is handled inconsistently in Iceberg with different file formats. (See: https://github.com/apache/iceberg/issues/1881 ) If we keep the type, it would be good to standardize the handling

[VOTE] Adopt the v2 spec changes

I’d like to propose that we adopt the pending v2 spec changes as the supported v2 spec. The full list of changes is documented in the v2 summary section of the spec . The major breaking change is the addition of delete files and metadata to track delete

[DISCUSS] UUID type

Hi. UUID is a current data type according to the Iceberg spec (https://iceberg.apache.org/spec/#primitive-types), but there seems to have been some discussion about removing it? I could not find the original discussion, but a reference to the discussion can be found here (https://github.com/t

Re: [DISCUSS] Distinct count map

Hi, Ryan, i agree on the NDV estimate (approximated number of distinct values) goal. Anton, re your question about Trino optimizer. I don't want to be overly focused on supporting current state to the extent that we make the future extensions impossible. On the other hand, it's worth knowing what

Re: Proposal: Support for views in Iceberg

Hi, Thanks Jack and Jacques for sharing your thoughts. I agree that tracking dialect/origin is better than nothing. I think having a Map {dialect: sql} is not going to buy us much. I.e. it would be useful if there was some external app (or a human being) that would write those alternative SQLs f

Re: [DISCUSS] Moving to apache-iceberg Slack workspace

Hi, I don't have opinion which Slack workspace this is in, as long as it's easy to join. Manual joining process is not healthy for sure. Btw, the apache-iceberg is currently limited to @apache.org emails, which some people do not have (e.g. i do not). Will you be sharing an invite link or somethin