Fix applyFilter when an Iceberg table does not have any snapshots

[alexjo2144]

Description

Tables created by Spark may not have a snapshot committed if they are newly created, empty tables.

Is this change a fix, improvement, new feature, refactoring, or other?

Fix

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

Iceberg connector

How would you describe this change to a non-technical end user or system administrator?

Fix handling of querying newly created, empty tables.

Related issues, pull requests, and links

Introduced by: #13239

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

( ) No release notes entries required.
(x) Release notes entries required with the following suggested text:

# Iceberg
* Fix querying Iceberg tables which are empty and contain no table history.

[ebyhr]

Tables created by Spark may not have a snapshot committed if they are newly created, empty tables.

Does it indicate that it would be better to fix CREATE TABLE logic in the connector?

[findepi]

Does it indicate that it would be better to fix CREATE TABLE logic in the connector?

This would have the benefit of improving test coverage, and support, for this case.

[findepi]

Suggested change

	.orElseGet(() -> ImmutableSet.copyOf(icebergTable.specs().keySet()));
	// No snapshot, so no data. This case doesn't matter.
	.orElseGet(() -> ImmutableSet.copyOf(icebergTable.specs().keySet()));

[ebyhr]

This would have the benefit of improving test coverage, and support, for this case.

Sorry, my comment was unclear. My question was if we will fix Iceberg CREATE TABLE logic to make it the same behavior with Spark after merging this PR as-is.

[alexjo2144]

Both are valid, going strictly by the specification. I don't know that matching the Spark behavior buys us anything besides making it easier to test this edge case where there are not snapshots in the history.

[findepi]

matching the Spark behavior buys us anything besides making it easier to test this edge case

that's the sole reason I'd consider this doing for.

however, i actually value the fact that table history (snapshots) contains entry for initial empty state. This indeed is part of the table history.