Xuanwo opened a new issue, #55:
URL: https://github.com/apache/iceberg-rust/issues/55
We haven't talked about [Iceberg
Views](https://iceberg.apache.org/view-spec/) yet and I'm not sure if you would
like to support them in the future. I'm actually really interested in using
views.
I don't want to include view support in this PR but I would like to future
proof the catalog design to easily support views in the future.
The REST catalog is in the
[process](https://github.com/apache/iceberg/pull/7913) of adding view support.
However, I have the feeling that the initial REST catalog API wasn't designed
with views in mind. There is one issue that comes up with the current design
that we might be able to avoid for our catalog design. I will try to explain
the issue.
Imagine a query engine wants to perform a query like the following:
```sql
SELECT first_name, last_name, age FROM users WHERE age > 18;
```
Without the catalog information the query engine doesn't know whether
`users` refers to a view or a table. So if the catalog only exposes a
`load_table` and `load_view` operation, the query engine doesn't know which one
to call. I would prefer a `load_tablelike` (the naming is not important)
operation that returns an
```rust
enum TableLike {
Table(Table),
View(View)
}
```
All iceberg catalogs except for the REST catalog return a "table metadata
location" and it would be easy to distinguish between Tables and Views based on
the metadata.
Let me know what you think.
_Originally posted by @JanKaul in
https://github.com/apache/iceberg-rust/issues/54#issuecomment-1702390543_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
