cloudbase-ai opened a new issue, #7520: URL: https://github.com/apache/shenyu/issues/7520
## Problem openGauss maintains a separate full initialization script from PostgreSQL despite sharing much of its SQL syntax and schema. Schema, seed-data and plugin migration changes must be repeated, and the copies have already drifted. We should remove this duplicate maintenance surface while preserving openGauss support. ## Evidence Inspected master at `3116109d42f4e6ca0e71258e15ec5ed051bdc4a1`: - [PostgreSQL initialization](https://github.com/apache/shenyu/blob/3116109d42f4e6ca0e71258e15ec5ed051bdc4a1/db/init/pg/create-table.sql) and [openGauss initialization](https://github.com/apache/shenyu/blob/3116109d42f4e6ca0e71258e15ec5ed051bdc4a1/db/init/og/create-table.sql) are not equivalent today. PostgreSQL creates a UNIQUE index on `discovery_upstream(discovery_handler_id, upstream_url)`; openGauss creates a non-unique index on those columns. Permissions, plugin handles and some table definitions also differ. - `.github/scripts/native-sql-matrix.py` selects `db/init/og/create-table.sql` for its native openGauss job. - `shenyu-e2e/shenyu-e2e-case/k8s/script/storage/storage_init_opengauss.sh` copies that same openGauss script into the E2E database initialization directory. - Runtime openGauss configuration and MyBatis interceptors are distinct. Sharing an initialization source does not justify removing those integrations. ## Requested Change - Use `db/init/pg/create-table.sql` as the canonical initialization source for PostgreSQL and openGauss wherever native compatibility is verified. - Reconcile existing table, constraint, index and seed-data differences first. In particular, resolve the discovery-upstream uniqueness difference explicitly rather than silently dropping a constraint during consolidation. - Delete the independently maintained `db/init/og/create-table.sql` after updating the native SQL runner, E2E storage initialization, packaging and documentation references. Keep only a small explicit compatibility overlay for any proven engine-specific SQL requirement. - Preserve openGauss profiles, JDBC driver, runtime dialect handling, native database validation and storage E2E coverage. - Leave historical upgrade scripts intact; any consolidation of those scripts requires a separate upgrade compatibility review. ## Acceptance Criteria - Native PostgreSQL and openGauss CI initialize from the same canonical source (plus any documented minimal overlay), and both pass on their supported versions. The openGauss storage E2E setup uses that source as well. - Fresh installations preserve the intended schema, uniqueness guarantees and plugin/resource/permission/default-namespace seed semantics, with no orphan relations or duplicate handle natural keys. - No independently maintained openGauss full initialization copy or dangling reference remains. Database support and installation documentation remain usable. -- 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]
