[VOTE] Update row lineage spec ID assignment

Hi everyone, I’d like to start a vote to incorporate the spec changes in PR 12781 . There are two main changes. First, the current language says that upgrading a table to v3 leaves all row IDs null and they are assigned when the rows are rewritten for

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Thanks Eduard and Sung! I have addressed the comments. One key point to keep in mind is that catalog names in the spec refer to logical catalogs—i.e., the first part of a three-part identifier. These correspond to Spark's DataSourceV2 catalogs, Trino connectors, and similar constructs. This is a l

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Thank you Walaa for the proposal. I think view portability is a very important topic for us to continue discussing as it relies on many assumptions within the data ecosystem for it to function like you've highlighted well in the document. I've added a few comments around how this may impact the pe

Re: [DISCUSS] Events Endpoint for IRC

Dear all, after the last Catalog sync I updated the proposal. Changes are in the original proposal Document [1] and the original PR [2] Best, Christian [1] https://docs.google.com/document/d/1WtIsNGVX75-_MsQIOJhXLAWg6IbplV4-DkLllQEiFT8/edit?usp=sharing [2] https://github.com/apache/iceberg/pull/1

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Thanks Walaa for tackling this problem. I've added a few comments to get a better understanding of how this will look like in the actual implementation. Eduard On Tue, Apr 15, 2025 at 7:09 PM Walaa Eldin Moustafa wrote: > Hi Everyone, > > Starting this thread to resume our discussion on how to

Re: [DISCUSS] Inconsistent NoSuchNamespaceException handling in REST Catalog API specification

Thanks for pointing this out Pascha and I can try and add some historical context to this. I believe the reason why this is currently done this way in the *OpenAPI* spec and in the *ErrorHandler* is because this is the behavior that has been defined in the Catalog

Re: [DISCUSS] Introducing Iceberg Features ?

Hi Eduard You all convinced me, I just wanted to get your feedback as I remember some kind of "additional" complexity while adding views support to the JDBC Catalog or working on multi-args transforms. Just a "flag" would have simplified a bit the code (for instance for JDBC Catalog, we have to ch

Re: [DISCUSS] Introducing Iceberg Features ?

I fully agree with what Fokko said and I'm concerned that this adds a lot of new complexity and also leads to engines only supporting a minimal set of features for a given Spec version, which makes it even harder for users to know what subset of features a V3 compliant engine actually supports. Ed