Hi, Ray. Spark and JDBC both allow pattern-based filtering in getSchemas and getTables calls [1][2][3][4]. I think it makes sense to follow the same approach for consistency.
Best, Shengkai [1] https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getSchemas-java.lang.String-java.lang.String- [2] https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTables-java.lang.String-java.lang.String-java.lang.String-java.lang.String:A- [3] https://github.com/apache/spark/blob/master/sql/api/src/main/scala/org/apache/spark/sql/catalog/Catalog.scala#L90 [4] https://github.com/apache/spark/blob/master/sql/api/src/main/scala/org/apache/spark/sql/catalog/Catalog.scala#L64 Ryan van Huuksloot <[email protected]> 于2025年9月28日周日 12:33写道： > Hi Shengkai, > > I agree that a page_token would work better so you can properly handle > pagination. If we are open to adjusting the Catalog API enough to optimize > so we can support page_tokens - and we would need to build a special rest > endpoint for this into (likely) the SQL Gateway. > > Do you feel similarly about passing the LIKE/ILIKE through to the Catalog > API? > > Ryan van Huuksloot > Staff Engineer, Infrastructure | Streaming Platform > [image: Shopify] > <https://www.shopify.com/?utm_medium=salessignatures&utm_source=hs_email> > > > On Sun, Sep 28, 2025 at 12:01 AM Shengkai Fang <[email protected]> wrote: > > > Hi Ryan. > > > > I am not sure it's a good idea to expose limit clause in the SHOW > > statements. As far as I know, many systems uses jdbc or client to list > > paged tables or views. For example, jdbc supports to list tables via > > DatabaseMetadata and ResultSet and databricks allow users to list paged > > tables using REST API[1]. I prefer to align the behaviour with databricks > > using special REST API and Catalog API to support this feature. > > > > [1] https://docs.databricks.com/api/workspace/tables/list#page_token > > > > Best, > > Shengkai > > > > Sriram Ganesh <[email protected]> 于2025年9月24日周三 13:47写道： > > > > > *Sriram G* > > > *Tech* > > > > > > > > > On Wed, 24 Sept 2025, 09:55 Ryan van Huuksloot, > > > <[email protected]> wrote: > > > > > > > Hi Everyone, > > > > > > > > I think it would be useful to add a LIMIT syntax with SHOW queries. > Or > > > have > > > > some sort of ability to show a subset of tables. > > > > > > > > It would be incredibly useful when working with catalogs that have > > > hundreds > > > > of databases and thousands of tables. In most cases folks want a > > > responsive > > > > UI and would prefer to click "load more" than wait a really long > time. > > > > > > > > I would propose that the default behaviour remains but the additional > > > > syntax is passed as a new set of overloaded methods in the Catalog. > I'd > > > > like to push this limit to the Catalog so the Catalog can decide if > it > > > > should filter before or after "loading" all of the objects. > > > > > > > > What do folks think? > > > > > > > > I think this will likely require a FLIP since it is quite a large > > change > > > to > > > > the SQL Gateway and Catalog. > > > > > > > > (Similarly, I think it would be useful to offer the ability to push > the > > > > LIKE predicate down to the Catalog. Therefore the developer can > > optimize > > > > the code if there is a predicate. Currently we do this after the rows > > are > > > > returned.) > > > > > > > > Ryan van Huuksloot > > > > Staff Engineer, Infrastructure | Streaming Platform > > > > [image: Shopify] > > > > < > > https://www.shopify.com/?utm_medium=salessignatures&utm_source=hs_email > > > > > > > > > > > > > >
