Change RowExpressionFormatter output to be closer to valid SQL

[lightseba]

RowExpressionFormatter outputs the type before any constant
(e.g BIGINT 5) for debugging purposes. This is not valid SQL,
so the constant is now output with TypeConstructor (e.g BIGINT'5'),
except for VARBINARY constants, which use the binary literal
syntax (e.g. X'abc123').

RowExpressionFormatter outputs LIKE expressions such as
column LIKE 'pattern%'
as
LIKE(column, CAST(VARCHAR pattern% as LikeExpression))
and LIKE expressions with ESCAPE, such as
column LIKE '$_pattern%' ESCAPE '$'
as
LIKE(column, LIKE_PATTERN(VARCHAR pattern%, VARCHAR $))
The output for LIKE expressions was changed to be valid SQL.

Test plan - unit tests

== RELEASE NOTES ==

General Changes
*  Improved RowExpressionFormatter output to be closer to valid SQL. 
   Constant expressions are now output as ``TYPE 'value'`` 
   (e.g. ``BIGINT'2'``) using TypeConstructor (with single quotes appearing 
   in the string escaped with ``''``), with the exception of ``VARBINARY`` 
   constants, which use the binary literal syntax (e.g. ``X'abc123'``). 
   ``LIKE`` expressions are now output as valid SQL.

[rongrong]

If you want them to be valid prestoSQL they should be in the format of TYPE'value'. For example, bigint'5'. While /*BIGINT*/5 is valid SQL, you might have errors parsing them back because 5 might be resolved to integer rather than bigint for example.

[kaikalur]

LGTM

[lightseba]

If you want them to be valid prestoSQL they should be in the format of TYPE'value'. For example, bigint'5'. While /*BIGINT*/5 is valid SQL, you might have errors parsing them back because 5 might be resolved to integer rather than bigint for example.

done

[rongrong]

Why is varbinary treated differently rather than using varbinary'xxx'?

[lightseba]

It seems like using TypeConstructor on varbinary takes the UTF-8 encoded version of the string as the binary literal, instead of reading it like a hex string. For example, when I run SELECT varbinary'abc123', x'abc123', varbinary'😎' on a local Presto server, I get

presto:sf1> SELECT varbinary'abc123', x'abc123', varbinary'😎';
       _col0       |  _col1   |    _col2    
-------------------+----------+-------------
 61 62 63 31 32 33 | ab c1 23 | f0 9f 98 8e 

I'm not sure if this is intentional behavior or not, but since varbinary literals are output as hex strings, I needed this workaround.

[rongrong]

A better way of doing this might be to change the ConstantExpression.toString() rather than putting this complex logic here.

[lightseba]

I moved it into a function LiteralInterpreter.evaluateToString(), since turning the constant to a string requires the relevant ConnectorSession and LiteralInterpreter.evaluate() contains similar logic. Thoughts?

[rongrong]

Sorry I didn't pay close attention. If it's not possible to move this to ConstantExpression, let's keep the logic in RowExpressionFormatter. Thanks!

[rongrong]

You can get the type name generically with type.getTypeSignature().getBase()

[lightseba]

done

[rongrong]

No space between type and value

[lightseba]

It seems like a space is allowed:

presto:sf1> SELECT bigint'5', TYPEOF(bigint'5'), bigint '5', TYPEOF(bigint '5'); 
 _col0 | _col1  | _col2 | _col3  
-------+--------+-------+--------
     5 | bigint |     5 | bigint 

Is it better to have no space anyways?

[rongrong]

ya more like a nit.

[lightseba]

done