fix: Reading a table with positional deletes should fail

[Fokko]

Here we fail:

iceberg-rust/crates/iceberg/src/scan.rs

Lines 449 to 454 in 74a85e7

	if manifest_entry_context.manifest_entry.content_type() != DataContentType::Data {
	return Err(Error::new(
	ErrorKind::FeatureUnsupported,
	"Only Data files currently supported",
	));
	}

But then the manifest is already filtered:

iceberg-rust/crates/iceberg/src/scan.rs

Line 625 in 74a85e7

.filter(|manifest_file| manifest_file.content == ManifestContentType::Data);

So it is unreachable, and it allows to return invalid data. Instead we should raise an error.

As always, don't hold back on my rust code :)

[Fokko]

This is important, otherwise we get many small parquet files with a single row. When a positional delete hits the Parquet file with one row, the parquet file gets dropped instead of having a merge-on-read delete file.

[kevinjqliu]

nit: add this comment alongside the code itself

also curious why its needed here, we use the same logic in pyiceberg https://github.com/apache/iceberg-python/blob/1278e8880c4767287dc69208ced20bd444c37228/dev/provision.py#L25

[Fokko]

I recall that I ran into the same thing with PyIceberg, but not sure how I fixed it there. Maybe good to add it there as well. Having a lot of partitions doesn't make any sense anyway, and will slow down the tests.

[kevinjqliu]

yep! 2 birds 1 stone :)

apache/iceberg-python#1417 (comment)

[liurenjie1024]

+1 for adding this comment along code.

[Fokko]

I forgot to git add the comment 🤦 It is there now

[kevinjqliu]

Great catch! Added a few nit comments

[kevinjqliu]

nit: add this comment alongside the code itself

also curious why its needed here, we use the same logic in pyiceberg https://github.com/apache/iceberg-python/blob/1278e8880c4767287dc69208ced20bd444c37228/dev/provision.py#L25

[liurenjie1024]

Thnaks @Fokko for this fix! Just left some nits, others LGTM!

[liurenjie1024]

+1 for adding this comment along code.

[Xuanwo]

Thank you @Fokko to get this fixed, and also thank you @kevinjqliu and @liurenjie1024 for review.