[
https://issues.apache.org/jira/browse/CALCITE-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18079415#comment-18079415
]
krooswu edited comment on CALCITE-7475 at 5/8/26 10:16 AM:
-----------------------------------------------------------
I did some research on the {{::}} cast syntax support across major SQL engines
and data warehouses.
It turns out that support is actually very broad across the ecosystem, not just
PostgreSQL:
* PostgreSQL
* Snowflake
* BigQuery
* Redshift
* ClickHouse
* DuckDB
* Vertica
* Trino
* Spark SQL / Databricks
* Doris / StarRocks
So at this point, {{::}} seems closer to a de-facto SQL ecosystem convention
rather than a niche dialect feature.
Also, semantically, I agree that {{::}} is essentially syntactic sugar for
{{{}CAST{}}}, and in the current implementation it is normalized directly into
a {{CAST}} expression during parsing. There is no semantic difference intended
between:
{{expr::type}}
and
{{CAST(expr AS type)}}
Because of that, I think modeling it as a dedicated parser/operator syntax
(while still lowering to {{{}CAST{}}}) is reasonable.
Regarding standard vs dialect-specific placement, my concern is that
restricting {{::}} too heavily may actually reduce interoperability, since many
modern engines already accept it as common SQL syntax.
That said, I agree we should still ensure it does not interfere with other
operators or grammar extensions, and conformance gating could still be applied
if needed.
was (Author: JIRAUSER308217):
I did some investigation on the {{::}} cast syntax support across major SQL
engines and data warehouses.
It turns out that support is actually very broad across the ecosystem, not just
PostgreSQL:
* PostgreSQL
* Snowflake
* BigQuery
* Redshift
* ClickHouse
* DuckDB
* Vertica
* Trino
* Spark SQL / Databricks
* Doris / StarRocks
So at this point, {{::}} seems closer to a de-facto SQL ecosystem convention
rather than a niche dialect feature.
Also, semantically, I agree that {{::}} is essentially syntactic sugar for
{{{}CAST{}}}, and in the current implementation it is normalized directly into
a {{CAST}} expression during parsing. There is no semantic difference intended
between:
{{expr::type}}
and
{{CAST(expr AS type)}}
Because of that, I think modeling it as a dedicated parser/operator syntax
(while still lowering to {{{}CAST{}}}) is reasonable.
Regarding standard vs dialect-specific placement, my concern is that
restricting {{::}} too heavily may actually reduce interoperability, since many
modern engines already accept it as common SQL syntax.
That said, I agree we should still ensure it does not interfere with other
operators or grammar extensions, and conformance gating could still be applied
if needed.
> Babel parser allows postfix access after PostgreSQL-style :: infix cast
> -----------------------------------------------------------------------
>
> Key: CALCITE-7475
> URL: https://issues.apache.org/jira/browse/CALCITE-7475
> Project: Calcite
> Issue Type: Improvement
> Components: babel
> Affects Versions: 1.41.0
> Reporter: Tamas Mate
> Assignee: krooswu
> Priority: Major
> Labels: pull-request-available
>
> In the Babel parser, InfixCast currently continues with regular postfix
> parsing after expr "::" type.
> This means the parser accepts postfix forms around "::" that go beyond a
> plain infix cast.
> Existing tests already cover examples such as:
>
> {code:java}
> select v.field::integer,
> arr[1].field::varchar,
> v.field.field2::integer,
> v.field[2]::integer
> from t
> select v::varchar array[1].field from t
> select (v::varchar array)[1].field from t{code}
>
>
> The current behavior is subtle because parentheses change how the postfix is
> associated. The existing tests expect:
>
>
> {code:java}
> select v::varchar array[1].field from t{code}
> to unparse as
>
>
> {code:java}
> SELECT `V` :: (VARCHAR ARRAY[1].`FIELD`)
> FROM `T`{code}
> while
>
>
> {code:java}
> select (v::varchar array)[1].field from t{code}
> unparses as
>
>
> {code:java}
> SELECT (`V` :: VARCHAR ARRAY[1].`FIELD`)
> FROM `T`{code}
> This ticket is to decide whether postfix access after "::" should be
> supported in Babel at all, and if so, to document and test the intended
> precedence rules more explicitly.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
