Thijs

As noted before, this is caused by duckdb not having support for schema qualifiers on replacement scans currently In the extension we currently work around this by setting the alias...

@mkaruza I am running into this problem again because of the problem we discussed yesterday, we currently use the `parse->rtable` list of RangeTblEntry objects, which include a possible alias. To...

```patch diff --git a/src/planner/binder/tableref/bind_basetableref.cpp b/src/planner/binder/tableref/bind_basetableref.cpp index 88739947b0..7b975cf86d 100644 --- a/src/planner/binder/tableref/bind_basetableref.cpp +++ b/src/planner/binder/tableref/bind_basetableref.cpp @@ -60,7 +60,7 @@ unique_ptr Binder::BindWithReplacementScan(ClientContext &context replacement_function->alias = ref.alias; } else if (replacement_function->alias.empty()) { // if the...

Actually found a way to not require changes to DuckDB 👍

It is still an issue yes, but it's probably far down the backlog

> this is fixed now right? If so, let's close it. Yes I just did some tests, the full qualification of the table references make this work entirely 👍

I believe this is not a problem anymore, `allow_moved_paths` is accepted everywhere and the codepath for supplying the `metadata.json` location directly and only giving the table path is the exact...

`iceberg_scan_deletes` was used when we still used the `bind_replace` path, this has been replaced with a much more sophisticated approach that allows much greater control over the scan and applying...

A lot of work has been done on improving the read path to take advantage of partition information in both the `manifest_list` as well as the `manifest_file`, based on available...

We don't support `hdfs` currently I believe