Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clickhouse SQL generation for datatypes. #1482

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

grigoryan-sergey
Copy link

The SQL generated by the parser does not work inside Clickhouse. The problem is in datatypes, which are case sensitive in Clickhouse. I suggest generating a Clickhouse version for datatypes. This will still work for other databases where datatypes are not case sensitive (like postgres) and will also work for Clickhouse. Interesting enough some datatypes are also not case sensitive in Clickhouse, but the ones which are case sensitive, are converted in the PR.

Copy link
Contributor

@iffyio iffyio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @grigoryan-sergey hmm with the current changes I expect a lot of tests to fail since we''ve also changed types that affect other dialects. I wonder if there's a way to support both styles 🤔 (I guess first would be if Clickhouse is the only supported dialect with a different behavior)

@grigoryan-sergey
Copy link
Author

Hi @iffyio. What do you mean by both styles? Camel case as in Clickhouse and uppercase notations? Currently in the code both of this styles are kind of mixed. I agree with you, it would be best to support both styles. In this PR I suggested to change only those which affect Clickhouse SQL generation.
Basically the styles were mixed before and are also mixed after the PR :). The problem with supporting two styles, is the complication. We need to introduce dialects not for just parsing but also for generating the SQL string. I am not that good at the knowledge of the codebase, so I cannot tell will it be complicated or not to implement. But my current proposal fixes the problem for the database which has case sensitive types (Clickhouse) and does not brake compatability (cases were mixed before and also after).

@iffyio
Copy link
Contributor

iffyio commented Nov 2, 2024

Ah yeah by both styles I mean that, today when displaying sql, the parser always uses upper case e.g. FLOAT64. While the changes in this PR updates that behavior such that for some types it now uses camel case Float64 - which I expect will break a lot of tests (and worse may be undesirable for other dialects). The changes aren't specific to clickhouse, Float64 for example is used by BigQuery.

I agree that it will be quite invasive to make this behavior configurable. On the other hand, I fear that using camel case for some types vs upper case for others will be quite haphazard (especially if Clickhouse isn't alone with this requirement).

Currently I'm not sure what a good way to approach this issue is actually 🤔

@pravic
Copy link

pravic commented Nov 2, 2024

@iffyio This looks like a job for the Dialect trait. Or for a new trait, e.g. Formatter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants