You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support the PostgreSQL :: cast operator for target types other than BYTEA #19628
#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.
Activity
Rewrite bytea constants in place to preserve Pinot statement nodes
Support PostgreSQL hex bytea literals (#19263)