terrymanu commented on issue #38651: URL: https://github.com/apache/shardingsphere/issues/38651#issuecomment-4556179364
Hi @Tracy0725, thanks for the question. This is an invalid-usage/question case rather than a ShardingSphere-Proxy bug. The `datcompatibility` column is handled as openGauss `pg_database` catalog metadata in ShardingSphere, not as standard PostgreSQL catalog metadata. If Proxy is configured with `proxy-frontend-database-protocol-type: PostgreSQL`, ShardingSphere binds the query against PostgreSQL system catalog metadata, so `SELECT datcompatibility FROM pg_database ...` is not supported in that mode. Please configure Proxy with `proxy-frontend-database-protocol-type: openGauss` when openGauss-specific catalog fields are expected. The 5.5.3 code already contains the openGauss handling for this query path, and the explanation in the thread was accepted by the issue author. I suggest labeling this as `type: question`, `status: invalid`, `in: Proxy`, and `db: openGauss`, then closing it as answered. If the same query can still be reproduced with `proxy-frontend-database-protocol-type: openGauss`, please provide `global.yaml`, the exact SQL, and the full error stack so we can reopen the technical investigation. The reply above is based on the analysis below; the detailed reasoning is kept here for reference and follow-up contributors. ### Problem Understanding - **Issue:** #38651 reports that ShardingSphere-Proxy 5.5.3 cannot recognize `pg_database.datcompatibility` when selecting that column explicitly. - **Topology:** Proxy access mode; PostgreSQL JDBC client; governance mode and registry/config center were not provided and do not affect this supportability decision. - **Observed Evidence:** `OBS-1`, `OBS-2`, `OBS-3`, `OBS-4`, `OBS-5`, `OBS-6` ### Root Cause - **Observation:** `OBS-1` The issue body reports ShardingSphere-Proxy 5.5.3, expected recognition of `datcompatibility`, and actual `Unknown column` behavior for explicit selection. Source: https://github.com/apache/shardingsphere/issues/38651 - **Observation:** `OBS-2` A community maintainer reproduced the issue and explained that `datcompatibility` is openGauss-specific and requires `proxy-frontend-database-protocol-type: openGauss`; the author replied `ok, thanks`. Source: https://github.com/apache/shardingsphere/issues/38651#issuecomment-4470992899 - **Observation:** `OBS-3` The 5.5.3 Proxy properties doc lists `proxy-frontend-database-protocol-type` and states that it supports `MySQL`, `PostgreSQL`, and `openGauss`. Source: https://shardingsphere.apache.org/document/5.5.3/en/user-manual/shardingsphere-proxy/yaml-config/props/ - **Observation:** `OBS-4` The property is defined as a `DatabaseType` property in `infra/common/src/main/java/org/apache/shardingsphere/infra/config/props/ConfigurationPropertyKey.java:73`. - **Observation:** `OBS-5` PostgreSQL `pg_database` metadata defines standard columns but not `datcompatibility`: `database/connector/dialect/postgresql/src/main/resources/schema/postgresql/pg_catalog/pg_database.yaml:18`. - **Observation:** `OBS-6` openGauss `pg_database` metadata defines `datcompatibility`: `database/connector/dialect/opengauss/src/main/resources/schema/opengauss/pg_catalog/pg_database.yaml:108`. - **Observation:** `OBS-7` The openGauss Proxy path routes `SELECT datcompatibility FROM pg_database` to `OpenGaussSelectDatCompatibilityExecutor`: `proxy/backend/dialect/opengauss/src/main/java/org/apache/shardingsphere/proxy/backend/opengauss/handler/admin/factory/OpenGaussSystemTableQueryExecutorFactory.java:72` and `proxy/backend/dialect/opengauss/src/test/java/org/apache/shardingsphere/proxy/backend/opengauss/handler/admin/factory/OpenGaussSystemTableQueryExecutorFactoryTest.java:53`. - **Inference:** The failure is caused by using PostgreSQL frontend catalog semantics while expecting openGauss-specific catalog semantics. Current ShardingSphere supports this field through the openGauss frontend path, not the PostgreSQL frontend path. - **Confidence:** High ### Problem Analysis - **Issue Type:** Misunderstanding / Invalid Usage - **Evidence:** `OBS-3` and `OBS-4` show the frontend protocol is an explicit database-type setting; `OBS-5`, `OBS-6`, and `OBS-7` show the column exists and is handled only in openGauss metadata/Proxy code. - **Label Recommendation:** `type: question`, `status: invalid`, `in: Proxy`, `db: openGauss` ### Problem Conclusion - **Evidence Confidence:** High - **Impact Scope:** Single Proxy protocol/configuration scenario for openGauss-specific system catalog metadata. - **Topology:** Proxy + unknown governance mode; registry/config center N/A/unknown. - **Issue Type:** Misunderstanding / Invalid Usage - **Recommended Labels:** `type: question`, `status: invalid`, `in: Proxy`, `db: openGauss` - **Next Action:** Configure `proxy-frontend-database-protocol-type: openGauss` for openGauss-specific catalog fields, and close this issue as answered/invalid usage unless it is reproducible with the openGauss frontend protocol. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
