Add support for PostgreSQL :: style casts

[dain]

Description

This PR proposes adding PostgreSQL style double colon :: casts to Trino. I find the standard SQL cast CAST(something as BIGINT) is quite wordy and difficult to write compared to :: especially when it is necessary to drop casts into existing queries (due the the strict nature of SQL type system). I find being able to drop a simple ::type on a symbol reference or function call to be super easy in PostgreSQL.

Fixes #23795

Release notes

(X) Release notes are required, with the following suggested text:

## Section
* Add support for PostgreSQL style `::` casts. ({issue}`25259`)

[martint]

See #23795 (comment)

[dain]

See #23795 (comment)

@martint that sounds great. It means that we have no concern that something useful will be used for this. I don't see us ever implementing that part of the spec, so we can use this operator for something awesome.

[martint]

I don't see us ever implementing that part of the spec, so we can use this operator for something awesome.

On the contrary. It's something I can envision supporting. E.g., you could do integer::to_hex(...), which, among other things, could help to avoid some tricky function overloading scenarios.

There are a few options for handling ambiguities:

• Fail the query when the a both a column::type and type::method are valid candidates for a given invocation
• Use a different operator instead of ::
• Use a slightly different syntax (e.g., instead of 123::varchar, use 123.as(varchar)), and treat it like method invocations on values -- similar to https://www.markhneedham.com/blog/2024/08/25/duckdb-chaining-functions/)

[wendigo]

What about syntax 11 AS BIGINT or 11 AS TYPE BIGINT ?

[electrum]

The ambiguity issue seems unlikely in practice, as you wouldn't declare a function with the same name as a type, except in the case where the function is an alias for a cast. For example, we support date(x) as a cast to date, so x::date would be the same, no matter which one is invoked.

The PostgreSQL cast syntax is well-understood by users and is quite convenient, so I vote to support it.

[electrum]

We can resolve the ambiguity by allowing it when the function is also a cast (as in the case of date), and failing the query otherwise. It looks like date is the only such function that exists today.

FunctionMetadata can have a new cast flag to indicate that the function is an alias for a cast, and ScalarFromAnnotationsParser can set the flag when the function is also a cast operator, probably in ScalarHeader.fromAnnotatedElement().

[ebyhr]

The current behavior with literals is ambiguous to me. For instance, I expected the following statement returns timestamp type at a glance, but it returns varchar type.

SELECT TIMESTAMP '2007-08-09 9:10:11 Europe/Berlin'::VARCHAR;

[dain]

The current behavior with literals is ambiguous to me. For instance, I expected the following statement returns timestamp type at a glance, but it returns varchar type.

SELECT TIMESTAMP '2007-08-09 9:10:11 Europe/Berlin'::VARCHAR;

I don't think that is ambigous. The first part of the expression is TIMESTAMP '2007-08-09 9:10:11 Europe/Berlin' is a type constructor in the grammar:

    | identifier string                                                                   #typeConstructor

Type constructors do not support an expression after the type name, and only support a literal string. Then the second part casts the timestamp to a varchar.

[electrum]

It is the same as if you wrote it with parentheses:

SELECT (TIMESTAMP '2007-08-09 9:10:11 Europe/Berlin')::VARCHAR;

The syntax for type constructors is special because they only support literals, not expressions. But I agree in this instance that is appears confusing, as the cast operator goes left-to-right instead of the typical inside-out for function calls. Visually, it's also confusing because the type constructor has a space inside of it, but the there's no separation between the string literal and the cast operator.

It's good to call out this edge case in the SQL syntax, but I don't have a good solution, other than mentioning it in the documentation. PostgreSQL should have the same issue.

[dain]

I expect people won't mix the syntax, and instead would do this:

'2007-08-09 9:10:11 Europe/Berlin'::TIMESTAMP

So the original expression would be:

'2007-08-09 9:10:11 Europe/Berlin'::TIMESTAMP::VARCHAR