#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.
#19263 adds the PostgreSQL
::infix cast operator to Pinot's SQL grammar, but only for hex-formatbyteaconstants such as'\x0102'::bytea. Every other target type is rejected at parse time, with an error that points toCAST(<expr> AS <type>).That limit is about scope, not a technical constraint.
SqlLibraryOperators.INFIX_CASTis an ordinarySqlCastOperatorof kindCAST. If the rejection is removed,intCol::doublealready compiles to the samecastfunction asCAST(intCol AS DOUBLE).Supporting
::for every type would need decisions on:::currently parses its target with Calcite'sDataType()production, the same oneCASTuses. PostgreSQL users will write names likeint4,int8,float8,textandtimestamptz, 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.col::type[1], the item accessor binds tighter than::. PostgreSQL has the same rule, but it is easy to get wrong.byteacasts. Shouldcol::byteaconvert per row, and with what semantics? In PostgreSQL,'0102'::byteais 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.