Re: [VOTE] Release Apache PyIceberg 0.9.1rc1

+1 (non binding) I checked: - LICENSE and NOTICE are good in the source distribution - ASF header present in all expected files - Hash and checksum are good - test and test-coverage work from source distribution Thanks ! Regards JB On Fri, Apr 25, 2025 at 5:05 PM Fokko Driesprong wrote: > > Hi

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

To help folks catch up on the latest discussions and interpretation of the spec, I have summarized everything we discussed so far at the top of the proposal document (here ). I have slightly updated the pr

Re: [VOTE] Release Apache Iceberg 1.9.0 RC2

+1 (binding) - Checked the signatures, checksum and licenses. - Did some checks against example notebooks. Thanks for running this release! Kind regards, Fokko Op wo 23 apr 2025 om 21:41 schreef Russell Spitzer < russell.spit...@gma

[VOTE] Release Apache PyIceberg 0.9.1rc1

Hi Everyone, I propose releasing the following RC as the official PyIceberg 0.9.1 release. Thanks everyone for contributing! A list of patches that went into this release: - https://github.com/apache/iceberg-python/milestone/11?closed=1 The commit ID is 7e1cfd18e3f8089eeae165a4092bf94305a812

Re: [VOTE] Release Apache Iceberg 1.9.0 RC2

+1 (binding) * checked signatures / checksum * ran tests using JDK 17 * ran Spark quickstart examples and a few manual tests Thanks for running the release Ajantha. Eduard On Fri, Apr 25, 2025 at 3:22 PM Fokko Driesprong wrote: > +1 (binding) > > - Checked the signatures, checksum and license

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

@Walaa: I would argue that when you run a CREATE VIEW statement the query engine knowns which catalog the view is being created in. So even though we typically use late binding to resolve the view catalog at query time, it can also be used at creation time. The query engine would need to kee

Re: [VOTE] Release Apache Iceberg 1.9.0 RC2

+1 (binding) 1. checked sigs/checksum/license 2. ran tests using JDK 17 Thanks for running the release! Best regards, Honah On Fri, Apr 25, 2025 at 8:47 AM Eduard Tudenhöfner wrote: > +1 (binding) > > * checked signatures / checksum > * ran tests using JDK 17 > * ran Spark quickstart ex

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Hi Jan, Thanks again for continuing the discussion. I want to highlight a few fundamental issues around the interpretation of default-catalog: Here is the real catch: * default-catalog cannot logically be defined at view creation time. It would be circular: the view needs to exist before its met

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

The core issue is on the fall back behavior when `default-catalog` is not defined. Current view spec says the fallback should be the catalog where the view is defined. It doesn't really matter what the catalog is named (catalogX) by the read engine. - If a view refers to the tables in the same cata

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Thanks Steven! How do you recommend making Spark implementation conform to the spec? Do we need Spark SQL extensions and/or Spark catalog APIs for that? How do you recommend reconciling the inconsistencies I shared regarding many resolution methods not consistently being followed in different scen

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

I'd like to contribute my opinions on this: - I don't particularly like the current behavior of "default to the view's catalog when default-catalog is not set". Fundamentally, I believe the intent of default-catalog and default-namespace is there to help users write more concise SQL. - spark sess

Re: [DISCUSS] Table Identifiers in Iceberg View Spec

Thanks for the contribution Benny! +1 to the confusion the fallback creates. Also just to be clear, at this point and after clarifying the current spec intentions, I am convinced that we should remove the default catalog and default namespace fields altogether. Thanks, Walaa. On Fri, Apr 25, 2025