schizophrenicmaniac commented on PR #40212: URL: https://github.com/apache/shardingsphere/pull/40212#issuecomment-6245525312
@terrymanu Thanks for going through it again. This round made it clear that decoding OID 0 text in Java before PostgreSQL sees it keeps hitting cases where the two disagree, so I pulled most of that back instead of patching each type. Bind now follows the same flow as master. Values are read with the types the client sent, so OID 0 values stay text, and the existing post-read resolution through JDBC metadata runs with those values rather than with an empty parameter list. The only new step sits between the two. An OID 0 value that is compared with (`=`, `<`, `>`, `<=`, `>=`, `IN`, `BETWEEN`) or assigned to (INSERT values, UPDATE SET) an int4 or int8 column is decoded to Integer or Long, based on the bound column metadata. That only happens when its text is a plain decimal integer with an optional sign and surrounding whitespace, and it fits the range. Anything else, like `0x1F`, `1_000` or an out-of-range number, stays text and PostgreSQL decides. A parameter used with columns of different types also stays text. That's enough to route integer sharding keys like the pgbench case without changing what reaches the backend for everything else. 1, 2 and 3: dates, timestamps, jsonb, bytea and numeric values are no longer decoded early, so on Bind they go to PostgreSQL as text like before. Surrounding whitespace is accepted for the integer case. I reverted the bool, numeric and timestamp parser changes and the TIMESTAMPTZ mapping, since nothing in this PR decodes through them any more. 4: the empty-parameter route and `loadForParameterMetadata` are gone. The metadata load on Bind uses the values that were read, with integer sharding keys already decoded. 5: `hasUnspecifiedParameterTypes` now only looks at the slots referenced by `actualParameterMarkerIndexes`, so the padded slot of `$1 OR $1` no longer triggers a metadata load on every Bind. There's a test for that case. 6 and 7: the Bool parser test and the metadata factory test were reverted along with the code they covered, and `getParameterType` was removed, so both no longer apply. Varchar sharding keys with OID 0 still aren't handled. A column reported as VARCHAR can also be an enum, and binding a Java String there would send varchar and fail where text works today. -- 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]
