xiangfu0 opened a new issue, #19628: URL: https://github.com/apache/pinot/issues/19628
[#19263](https://github.com/apache/pinot/pull/19263) adds the PostgreSQL `::` infix cast operator to Pinot's SQL grammar, but only for hex-format `bytea` constants such as `'\x0102'::bytea`. Every other target type is rejected at parse time, with an error that points to `CAST(<expr> AS <type>)`. That limit is about scope, not a technical constraint. `SqlLibraryOperators.INFIX_CAST` is an ordinary `SqlCastOperator` of kind `CAST`. If the rejection is removed, `intCol::double` already compiles to the same `cast` function as `CAST(intCol AS DOUBLE)`. Supporting `::` for every type would need decisions on: - **Type names.** `::` currently parses its target with Calcite's `DataType()` production, the same one `CAST` uses. PostgreSQL users will write names like `int4`, `int8`, `float8`, `text` and `timestamptz`, which Calcite treats as unknown user-defined types. We need to decide which PostgreSQL names to accept and how each maps to a Pinot type. - **Engine parity.** Each mapping needs to give identical results in the single-stage and multi-stage engines, with tests in both. - **Precedence.** In `col::type[1]`, the item accessor binds tighter than `::`. PostgreSQL has the same rule, but it is easy to get wrong. - **Dynamic `bytea` casts.** Should `col::bytea` convert per row, and with what semantics? In PostgreSQL, `'0102'::bytea` is escape-format input and yields four bytes, not a hex decode. Rejecting other target types for now keeps every option open. Relaxing a rejection later is backward compatible; narrowing a type the grammar already accepts would not be. -- 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]
