somiljain2006 commented on PR #39225: URL: https://github.com/apache/shardingsphere/pull/39225#issuecomment-5262515553
@terrymanu Thanks for the detailed review. My proposed design is: ### 1. Parameter state and wire OIDs I will replace the current `List<PostgreSQLBinaryColumnType>`-only representation with a per-parameter state object, such as `PostgreSQLParameterState`. The state will preserve the information required across Describe, Bind, repeated Bind, and batch execution, including the PostgreSQL wire OID, native type name where available, JDBC type where applicable, decoding strategy, and whether the type has been resolved. Raw `UNSPECIFIED` Bind values will remain raw until the parameter type is resolved. Once resolved, that state will be retained by `PostgreSQLServerPreparedStatement` and reused for subsequent Bind and batch executions. For JSON and JSONB, the state will preserve their distinct PostgreSQL identities rather than treating JSONB as JSON. For arbitrary `Types.OTHER`, the native type identity will be retained instead of mapping it to `VARCHAR`. I will also restore the existing PostgreSQL/openGauss `ColumnTypeOIDResolver` and `ColumnTypeOIDLoader` path so composite fields continue to use their actual database wire OIDs. ### 2. Per-marker schema ownership `ColumnSegmentBoundInfo` will be authoritative for parameter ownership. Resolution will use the complete database/schema/table/column information associated with each marker rather than selecting a statement-wide schema. If the exact owner cannot be resolved unambiguously, that marker will remain unresolved rather than being resolved against a same-named object from another schema. ### 3. Describe completeness and JDBC fallback I agree that partial inference must not be treated as complete. The metadata-only Describe path will only be used when all parameter/projection types required for the response have been resolved unambiguously through the existing semantic/Binder and schema metadata paths. If any required parameter or projection remains unresolved after those paths have been attempted—for example because of an unsupported expression, incomplete RETURNING ownership, or an ambiguous cross-schema reference—the statement will fall back to the existing JDBC metadata path. This means `UNSPECIFIED` can remain an intermediate Bind-first state; it is the unresolved state after resolution has been exhausted that triggers the fallback. ### 4. Test boundaries I will update the relevant tests so that Binder-dependent cases exercise the actual parsing/binding production path rather than manually injecting `ColumnSegmentBoundInfo`. The tests will cover Describe-first, Bind-first, repeated Bind, batch execution, standard VARCHAR, JSON/JSONB, arbitrary custom types, schema-qualified/cross-schema statements, nested expressions and RETURNING, PostgreSQL/openGauss composite OIDs, and the already-resolved text fast path. If this state model and completeness/fallback contract align with the intended architecture, I will proceed with `PostgreSQLParameterState` and the corresponding changes. -- 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]
