Hi I like the idea to just "get relation" to get the relation in one shot. Similar thing applies to listing relations. This is obviously less common operation, but not uncommon and also more expensive. BI tools query information_schema.tables (and other information_schema information). To complete information_schema.tables query we need to call "list tables" and "list views" separately, whereas it could be sufficient to "list relations".
Given than tables views and materialized views all share single namespace, such a unified API should be possible to add and definitely would be beneficial for users. Best, Piotr On Thu, 5 Dec 2024 at 08:53, Vladimir Ozerov <voze...@querifylabs.com> wrote: > Hi, > > Consider the query “SELECT * FROM t”. > > The query engine needs to resolve the object “t” during semantic analysis. > In Iceberg, this could be a table, a view, a materialized view (soon). > > Currently, the engine has to guess object type via multiple REST calls, > e.g loadTable -> loadView. This increases latency and REST server load, > bloats audit records, etc. > > Caching may help to some extent, but is not a general solution: doesn’t > work for one-shot executions (Spark), breaks security and audit, > inefficient in the case of near real-time ingestion, etc. > > Do you think it is worth adding an endpoint, which will return an object > metadata in one hop? Like “loadObject: oneof(Table, View)”. A careful > analysis may reveal more use cases potentially prompting even more generic > endpoint. > > If this was discussed earlier, could you kindly point me to the discussion > (couldn’t find one)? > > Regards, > Vladimir >
