terrymanu commented on PR #39225:
URL: https://github.com/apache/shardingsphere/pull/39225#issuecomment-5242574708
@somiljain2006 Your understanding is correct. Please use the following
architectural boundaries:
1. PostgreSQL parameter type resolution and state should be owned by the
PostgreSQL extended-protocol layer. `PostgreSQLServerPreparedStatement` should
retain the parameter type information required by Describe, Bind, repeated
execution, and batch execution. JDBC `ParameterMetaData` and schema metadata
are information sources, not state owners.
Before Bind parses a value using a concrete type, the prepared statement
must distinguish standard types, JSON, and custom types. If a Bind-first flow
requires raw parameters for routing, preserve the raw `UNSPECIFIED` values
until the types are known, and convert them afterward. Do not decode them as
JSON prematurely or map arbitrary `Types.OTHER` values to JSON. Reuse the
existing Binder or Describe statement semantics instead of maintaining another
partial AST traversal in the resolver.
2. `typeName` may become part of the shared column metadata because it
represents the database-native column type name. PostgreSQL may populate it
first while other dialects leave it `null`. However, it must be a complete
persistence contract, including `YamlShardingSphereColumn`,
`YamlColumnSwapper`, persistence and reload paths, and round-trip tests.
The revised implementation should also ensure that:
- Already-resolved text parameters retain the existing fast path without
additional routing, connection acquisition, or JDBC metadata queries.
- Implicit INSERT column lists, multi-row `VALUES`, UPDATE expressions, and
multi-table statements are resolved through the existing semantic owner.
- Tests cover Describe-first, Bind-first, repeated Bind, batch execution,
custom types, ordinary `VARCHAR`, metadata persistence round trips, and the
reused openGauss paths.
Please rework the implementation around these boundaries. The current
post-decoding fix and partial parameter-to-column mapping in the resolver
should not be extended further.
--
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]
