Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

When you convert WITH TIME ZONE types to TIME or TIMESTAMP, timezone is considered in the current version, but not in Presto 350. If you have queries that contain such conversion, you might need to revise them for Presto 350. In the previous example, the query can be rewritten as follows:


Code Block
linenumberstrue
SELECT CAST(

...

 

...

-- Convert to UTC before CAST as TIMESTAMP

...

 

...

TIMESTAMP '2000-01-01 00:00:00 US/Eastern' AT TIME ZONE 'UTC'

...

 AS TIMESTAMP)

In addition, political timezones (e.g. America/Los_Angeles) are no longer allowed in TIME WITH TIME ZONE, to avoid issues around DST and possible future policy changes.

Therefore, the following query works on the current version, but it doesn’t not on Presto 350.

Code Block
linenumberstrue
SELECT TIME '01:02:03.456 America/Los_Angeles'

Rewrite this query as follows:

Code Block
linenumberstrue
SELECT TIME '01:02:03.456 -07:00'

Query results can be also different. SELECT CURRENT_TIME generates 09:29:52.540 UTC on on the current version but ; in Presto 350, use 09:29:52.540+00:00 on Presto 350.

Query Length Limitation

Presto 350 could might generate a longer byte-code internally, so long queries may might hit the query length limitation.  If you get error messages like the following, you have need to shorten the query.

  • java.lang.IllegalArgumentException: bad parameter count 256

  • io.prestosql.spi.PrestoException: Query exceeded maximum columns

...

approx_percentile() now uses T-digest as an internal data structure, which is more accurate and faster than the previous version. The function will produce produces slightly different results.

However, if you specify the accuracy parameter, approx_percentile() doesn’t use T-digest because T-digest doesn’t allow the accuracy parameter. If you want to benefit from T-digest-based approx_percentile(), consider dropping the accuracy parameter.

Info
approx_percentile() doesn’t allow infinite values (value values divide by zero). If such a value is given, the query fails with java.lang.IllegalArgumentException: value must be finite. In this case, you have to exclude infinite values before approx_percentile(), or you can use the old version of approx_percentile() by specifying accuracy parameter intentionally as a workaround as follows:

...

Presto 350 doesn’t allow convert NaN value to INTEGER while , however, it can be converted to 0 by CAST in the current version. The following query works on the current version but fails on Presto 350 with Cannot cast double NaN to integer error message.

...

You can restore the original behavior by using TRY_CAST and COALESCE as follows.:

Code Block
linenumberstrue
SELECT COALESCE(TRY_CAST(nan() AS INTEGER), 0)

...