Allow fetching relation names with their types#19832
Conversation
|
cc @trinodb/maintainers |
github-actions
bot
added
jdbc
findepi
force-pushed
the
findepi/relation-types
branch
2 times, most recently
from
e8b3e21 to
8ef0cd0
Compare
There was a problem hiding this comment.
I don't think "relation" is a clearer term. Views, materialized views, etc. are all just "tables" - at least in anything associated with the SQL spec. If we're going to attempt to distinguish regular tables from views and friends, then we should be talking about derived tables, base tables, views, temporary tables, etc. which are all just "tables". A "regular" table (i.e., not a view or materialized view) is just a "base table".
There was a problem hiding this comment.
I see your point and agree from sql perspective. "tables" is an overloaded term and sometimes it refers to regular tables (not views), sometimes to any relations (tables per above). The confusion is amplified by "list tables" and "list views" methods living in same interface (ConnectorMetadata, or HiveMetastore). They look complementary, and i've seen people confused about them, but they are not. The Trino SPI handles tables and views differently (eg getTableHandle vs getView), despite them being "just tables" from SQL perspective, making the confusion even easier.
findepi
force-pushed
the
findepi/relation-types
branch
from
8ef0cd0 to
a4a33c5
Compare
The "tables" is often used to refer to tables only. "Relations" better indicates the method includes tables, views and materialized views. This is a preparatory step for introducing a method to list all relations with their types.
This reduces number of Glue calls when reading from `information_schema.tables` or `system.jdbc.tables`.
findepi
force-pushed
the
findepi/relation-types
branch
from
a4a33c5 to
b979ffe
Compare
|
Close this one since the alternative PR is merged? |
|
prep part resubmitted as #19920 |
4 participants
This reduces number of Glue calls when reading from
information_schema.tablesorsystem.jdbc.tables.