TSQL Convert

[TimothyAerts]

Hi,

First of all many thanks for this library, what an awesome tool!
I'm rather new to sqlglot so forgive me for any mistakes made in this question.
While trying to parse TSQL I came across an issue with CONVERT.
the parse_convert method assumes the CONVERT style of MYSQL, like this SELECT CONVERT("2017-08-29", DATE);.
In TSQL however the parameters are inversed like so: SELECT CONVERT(int, 25.65);

The problematic part in the current parse convert implementation is that the datatype in the tsql case is now parsed as an ID_VAR_TYPE instead of a datatype. Then the subsequent token that is the actual ID_VAR is not able to parse since the match fails.

What would be the preferable solution here?
I can quickly think of a few but wanted to check in with the contributors to ensure a solution within the guidelines of the module.
I suppose the preferred solution is to try and force the token into a datatype token and on failure parse it as id_var. This way both situations would be handled?
Or would it be preferred to overwrite the parse_convert specifically for the tsql dialect?

Any other suggestions are more than welcome.

Kind regards,
Timothy

[georgesittas]

Hello,

This has already been fixed in the main branch (see here). Make sure you're using T-SQL as the input dialect in the parser.

Regarding your examples:

>>> sqlglot.parse_one("SELECT CONVERT(DATE, '2017-08-29')", read='tsql')
(SELECT expressions:
  (CAST this:
    (LITERAL this: 2017-08-29, is_string: True), to:
    (DATATYPE this: Type.DATE, nested: False)))

>>> sqlglot.parse_one("SELECT CONVERT(int, 25.65)", read='tsql')
(SELECT expressions:
  (CAST this:
    (LITERAL this: 25.65, is_string: False), to:
    (DATATYPE this: Type.INT, nested: False)))

Or would it be preferred to overwrite the parse_convert specifically for the tsql dialect?

When it comes to changes like this, it's usually better to do the overwriting only for the target dialect, although this might not be the case if there are several dialects that can benefit from them.

[TimothyAerts]

Thank you for the swift answer and apologies for the lack of reading on my side (I was behind main).