can not obtain Information_SCHEMA.LUMNS

[Imdyh]

I cannot obtain shard table information from Information_SCHEMA.LUMNS, but I can obtain it from the actual shard table

[terrymanu]

1. Problem Understanding

Based on the current evidence, this issue cannot be confirmed as a bug yet.

Fast triage

1. Can the behavior be reproduced with version + mode + SQL + config + log evidence?
   No. The issue currently contains screenshots only, but does not include ShardingSphere version, deployment topology, database version, rule configuration, or logs.

2. Is the expected behavior explicitly documented in official ShardingSphere docs?
   No. I could not find official documentation stating that information_schema.columns must expose logical sharding tables. Instead, the official documentation states that ShardingSphere-Proxy has limited support for system databases/tables such as information_schema.

3. Do repository code/tests confirm a mismatch with the documented expectation?
   No clear mismatch was found.

Provisional classification

Needs More Info

At the moment, this looks closer to a metadata capability boundary / expectation mismatch than a confirmed defect.

---

2. Root Cause

Observations

• OBS-1: The screenshots show that:

  • SELECT * FROM information_schema.columns WHERE table_schema = 'zyhl_ims' AND table_name IN ('test_sharding') returns no rows.
  • The same query against physical tables test_sharding_0 and test_sharding_1 returns column metadata.
    Source: issue body of #38635

• OBS-2: Official docs explicitly state that ShardingSphere-Proxy provides limited support for system databases / tables such as information_schema and pg_catalog.
  Source: ShardingSphere-Proxy Quick Start

• OBS-3: Official docs provide logical metadata query capabilities through DistSQL, including:

  • SHOW TABLE METADATA
  • SHOW SHARDING TABLE NODES

• OBS-4: In the MySQL Proxy system-schema query path, only SCHEMATA has a dedicated special executor. Other system tables fall back to the generic metadata executor.
  Source:

  • MySQLSystemSchemaQueryExecutorFactory.java
  • MySQLSchemataQueryExecutorFactory.java

• OBS-5: The generic metadata executor opens a backend storage-unit connection and executes the original SQL directly. It does not rewrite information_schema.columns to use ShardingSphere logical table metadata.
  Source:

  • DatabaseMetaDataExecutor.java

• OBS-6: Existing tests cover the SCHEMATA special case and generic fallback behavior, but I did not find a MySQL Proxy test asserting that information_schema.columns must expose logical sharding tables.
  Source:

  • MySQLAdminExecutorCreatorTest.java
  • MySQLSystemSchemaQueryExecutorFactoryTest.java
  • SelectInformationSchemataExecutorTest.java

Inferences

• INF-1 (from OBS-1, OBS-4, OBS-5): The empty result for logical table test_sharding is consistent with current Proxy behavior: information_schema.columns is backed by physical MySQL metadata, which knows physical tables but not ShardingSphere logical table names.
  Confidence: Medium

• INF-2 (from OBS-2, OBS-3, OBS-4, OBS-5): The current behavior appears consistent with the documented limitation of information_schema support. The documented path for logical metadata access is DistSQL rather than information_schema.columns.
  Confidence: Medium

• INF-3 (from missing version/topology/config evidence): A version-specific regression still cannot be ruled out.
  Confidence: Low

---

3. Problem Analysis

The repository already exposes logical table metadata through dedicated Proxy features, but not through a documented guarantee on information_schema.columns:

• SHOW TABLES reads ShardingSphere schema metadata rather than simply exposing backend physical table names.
  Source:

  • MySQLShowTablesExecutor.java

• SHOW TABLE METADATA is the documented syntax for querying table metadata in Proxy.
  Source:

  • SHOW TABLE METADATA

• SHOW SHARDING TABLE NODES is the documented syntax for querying logical-to-physical sharding node mappings.
  Source:

  • SHOW SHARDING TABLE NODES

So with the current evidence, the issue is better understood as:

• the reporter expects MySQL-style information_schema.columns to expose logical sharding tables;
• current code path does not implement that logical metadata projection for information_schema.columns;
• official docs already state that support for system tables like information_schema is limited;
• official docs instead point users to DistSQL for logical metadata inspection.

However, the minimum evidence package is still incomplete, so a definitive final classification should wait for additional details.

---

4. Problem Conclusion

Current conclusion: Needs More Info

At this stage, I do not think there is enough evidence to confirm this as a bug.

Why

This conclusion is supported by OBS-1, OBS-2, OBS-4, OBS-5, INF-1, and INF-2:

• the reported behavior matches the current implementation path;
• the implementation path matches the documented limitation boundary for information_schema;
• the documented logical metadata query path is DistSQL, not information_schema.columns.

Minimum additional information needed

Please provide the following so the community can determine whether this is a documentation/expectation issue or an actual defect:

• ShardingSphere version
• Access mode: JDBC or Proxy
• Governance mode: Standalone or Cluster
• MySQL version
• Minimal sharding rule / YAML / DistSQL config for test_sharding
• Exact output of:
  • SHOW TABLES;
  • SHOW TABLE METADATA test_sharding;
  • SHOW SHARDING TABLE NODES test_sharding;
  • the current SELECT * FROM information_schema.columns ... query
• Whether this was executed via mysql CLI or a GUI client
• Relevant Proxy log snippets, if any

If no additional evidence is provided within 7-14 days, closing this issue as status: invalid would be reasonable.

[Imdyh]

ShardingSphere version is 5.5.2，use Standalone mode，mysql version is 8.0.30，tried via mysql CLI and GUI client，no logs were printed, including those for success and exceptions
Configuration as follows：

database-sharding.yaml

Exact output as follows:

[Imdyh]

@terrymanu Please review it again