Presto: MySQL connector doesn't support unsigned bigint

Created on 15 Aug 2018  路  4Comments  路  Source: prestodb/presto

We are running a query against a MySQL catalog in Presto, and receive the following error:

Query 20180815_131639_00036_4rnin failed: '9670921309777719314' in column '16' is outside valid range for the datatype BIGINT.

presto:default> desc articles;
        Column        |       Type        | Extra | Comment
----------------------+-------------------+-------+---------
...
 save_key             | bigint            |       |
...

Seems like the MySQL connector doesn't respect unsigned types?

Most helpful comment

Is there a reason for not having unsigned types?

In this particular case this field is bigint but used as a value (no computations; could have just been a string). Since Presto inferred the schema from MySQL automatically we didn't get the chance for a bypass (e.g. converting that field to String) and SELET * just fails.

I'd say Presto should either support unsigned types (because the downstream sources do), or at least let you cast those types to something else should you need it - but that has to be explicit, so I get to choose whether to use DECIMAL with a penalty or just a VARCHAR for the value.

All 4 comments

Presto doesn't have unsigned types. We can map unsigned bigint to DECIMAL(19). There will be some runtime penalty for this, as DECIMAL(n>=19, *) is backed by a Slice.

Is there a reason for not having unsigned types?

In this particular case this field is bigint but used as a value (no computations; could have just been a string). Since Presto inferred the schema from MySQL automatically we didn't get the chance for a bypass (e.g. converting that field to String) and SELET * just fails.

I'd say Presto should either support unsigned types (because the downstream sources do), or at least let you cast those types to something else should you need it - but that has to be explicit, so I get to choose whether to use DECIMAL with a penalty or just a VARCHAR for the value.

we didn't get the chance for a bypass (e.g. converting that field to String) and SELET * just fails.

Typically, a workaround would be to define a VIEW (in MySQL) over your TABLE that translates the column into something that works (varchar or decimal)

Duplicates #10017

Was this page helpful?
0 / 5 - 0 ratings