Fix information_schema.tables failure for redirected tables

[phd3]

No description provided.

[sopel39]

I'm not sure that is always a valid assumption. Do we check for existence of proper table handle in other places that use redirection?
IMO we should do the actual check, because it's cheap and target handle might not be valid

[findepi]

I think the point here is return correctly in

trino/core/trino-main/src/main/java/io/trino/metadata/MetadataManager.java

Lines 611 to 620 in 1bf4b65

	public List<QualifiedObjectName> listTables(Session session, QualifiedTablePrefix prefix)
	{
	requireNonNull(prefix, "prefix is null");
	Optional<QualifiedObjectName> objectName = prefix.asQualifiedObjectName();
	if (objectName.isPresent()) {
	if (isExistingRelation(session, objectName.get())) {
	return ImmutableList.of(objectName.get());
	}
	return ImmutableList.of();

we have options

• table that redirects correctly
• table that redirects to non-existent

including both cases in SHOW TABLES looks like a correct thing to do, since we cannot throw.

[sopel39]

Ok, so how do we handle redirections during listing (when no object name is provided)? We should be consistent with that

[phd3]

how do we handle redirections during listing (when no object name is provided)

unfiltered listTables doesn't care about redirections, just returns connector's results.

@findepi for the redirected+filtered case, do you mean we should try getting redirected table handle, and return empty if there's an exception doing that? That'd be closer to current filtered+unredirected case, but different from unfiltered+redirected case.

[findepi]

try getting redirected table handle, and return empty if there's an exception doing that?

that could be reasonable when we can emit a warning at the same time

for now, i would rather fail instead.
the situation where we do redirect but then get "404", looks like misconfiguration.
we're probably yet to learn what are the conditions where such situation would be legitimate (outside of our control)

[phd3]

@findepi does the fixup commit look better?

[sopel39]

So we don't filter on target table name? I though this redirection is logically similar to symlink so we perform every action (e.g access control checks) on targets.

[phd3]

for table listing, we don't filter on target. If a is redirected to b, we're only listing a, and not b. #7606 (comment)

[findepi]

the isExistingRelation is currently used only in io.trino.metadata.MetadataManager#listTables where we decided not to confirm table existence with the target catalog. The filtered case could be done consistently.
However, we currently have no SPI for checking relation existence without following redirects. getTableHandle would be that, but it also does additional checks ("not a Hive table", "not an iceberg table").

It seems we could benefit from consolidated resolveRelation SPI which would determine whether relation is a table, redirect, view or materialized view (#9400 cc @losipiuk).

For now, add a comment and maybe a TODO link.

Also, please expand the line

// If the table is redirected, but the target table handle is missing, an exception is thrown

-- currently it looks like the behavior is desireable, while it not necessarily is. It's just documenting current state of things.

[phd3]

@findepi AC

[phd3]

Merged #8684 into master.