truffle-dev commented on issue #22506: URL: https://github.com/apache/datafusion/issues/22506#issuecomment-4652996998
> As long as people won't experience a regression (as in queries that used to work start failing) following Postgres behavior seems reasonable to me The regression surface is narrow but specific: queries where the same `$N` appears in both a string-context and a numeric-context, or any other incompatible-family pair. Under `comparison_coercion` today those PREPARE successfully because `string_numeric_coercion` returns `Some(Int32)` for `(Int32, Utf8)` (the second-to-last `or_else` arm in `comparison_coercion`). Under Postgres-shape they would PREPARE-fail. Concrete shape that would change behavior: ```sql CREATE TABLE users(name VARCHAR, age INT); PREPARE q AS SELECT $1 = name, $1 = age FROM users; -- comparison_coercion path: Some(Int32) → PREPARE OK, may fail at EXECUTE on bad rows -- Postgres-shape path: operator-not-found at PREPARE ``` The surface should be rare in practice because parameter-using clients (JDBC, libpq drivers, sqlx etc.) typically generate queries with one consistent type per placeholder. One useful sanity check before flipping the policy: grep `PREPARE` across `datafusion/sqllogictest/test_files` for cross-family placeholder uses; if none of those break under the stricter merge, the regression risk is contained to user code outside the test suite. The string + temporal pair (`string_temporal_coercion`) is the other arm worth checking since it has the same permissive shape. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
