somiljain2006 commented on PR #39225:
URL: https://github.com/apache/shardingsphere/pull/39225#issuecomment-5100936446

   @terrymanu Thanks for the detailed review.
   
   I agree that we should first establish who should own PostgreSQL custom type 
resolution before continuing the implementation.
   
   My understanding of the current discussion is:
   
   * The root problem is that PostgreSQL custom types currently fall through 
the `Types.OTHER` path and can be classified as JSON.
   * The resolver I modified is likely too late in the Parse/Describe/Bind flow 
to be the authoritative owner of PostgreSQL type identity.
   * If `typeName` becomes part of the shared metadata model, it must also 
participate in persistence/reload rather than only exist in in-memory objects.
   
   Rather than continuing with the current resolver-based approach, I'd like to 
revisit the design first.
   
   My proposed plan is:
   
   1. Trace the complete extended protocol flow (Parse → Describe → Bind) to 
identify where `Types.OTHER` is first mapped to `PostgreSQLBinaryColumnType`.
   2. Move the custom-type resolution to that authoritative point instead of 
repairing it after decoding, and reuse existing Binder/Describe statement 
metadata where available rather than introducing a separate statement-to-column 
mapping in the resolver.
   3. Only if metadata is still required there, make `typeName` a complete 
metadata contract (including persistence); otherwise keep PostgreSQL-specific 
type information local to the protocol layer.
   4. Keep the existing fast path for already-resolved parameters so ordinary 
text binds don't incur additional metadata lookups.
   
   Does that direction align better with the intended ownership, or is there 
another component in the PostgreSQL protocol pipeline where you'd prefer this 
logic to live?
   


-- 
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]

Reply via email to