[
https://issues.apache.org/jira/browse/CALCITE-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18079182#comment-18079182
]
Mihai Budiu commented on CALCITE-7475:
--------------------------------------
I don't know what the criteria are for moving something to the standard
operator table, but I think that table is way too large, it really should
contain operators that are "standard".
An operator cannot be there if having it prevents other operators from being
added. An example is the "colon" operator under work now, which needs a special
conformance level. I haven't looked to see whether double colon would have
similar problems.
Moreover, if only few dialects support an operator, it probably should not be
in the standard operator table.
The double colon operator has the nice property that it's just syntactic sugar
- it should be fully equivalent with a CAST. So in some sense maybe you don't
even need a new operator - the parser can directly create a CAST if possible.
Is there a semantic difference between :: and cast?
> 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)
