Skip to content

Support the PostgreSQL :: cast operator for target types other than BYTEA #19628

Description

@xiangfu0

#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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions