You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have noted that table names or column names in mixed case cause queries generated from SQL to fail. This is a combination of two things. First, our code always does 'respect case' comparisons. Second, even if you write mixed case in the SQL query, the presto parser converts all identifiers to lower case internally. Today, you have to know that this lowercasing is happening and you have to ensure that all table and column names are all lower case.
Jerome says that Presto's contribution to this problem is considered a bug by them.
There is also the fact that (1) it is surprisingly unclear what the SQL standard calls for and (2) most implementations don't adhere to any version of the SQL standard 100%. So, in practice, SQL sometimes calls for ignoring case and sometimes respecting it during comparisons. I believe the SQL 92 standard, at least, actually says that unquoted identifiers should be compared while ignoring case whereas quoted ones should be compared while respecting case.
Probably the only real solid long-term solution to this is to support both ignore-case and respect-case comparison operators in across our internal languages and identify which is called for in the front-end translation from SQL.
The text was updated successfully, but these errors were encountered:
We have noted that table names or column names in mixed case cause queries generated from SQL to fail. This is a combination of two things. First, our code always does 'respect case' comparisons. Second, even if you write mixed case in the SQL query, the presto parser converts all identifiers to lower case internally. Today, you have to know that this lowercasing is happening and you have to ensure that all table and column names are all lower case.
Jerome says that Presto's contribution to this problem is considered a bug by them.
There is also the fact that (1) it is surprisingly unclear what the SQL standard calls for and (2) most implementations don't adhere to any version of the SQL standard 100%. So, in practice, SQL sometimes calls for ignoring case and sometimes respecting it during comparisons. I believe the SQL 92 standard, at least, actually says that unquoted identifiers should be compared while ignoring case whereas quoted ones should be compared while respecting case.
Probably the only real solid long-term solution to this is to support both ignore-case and respect-case comparison operators in across our internal languages and identify which is called for in the front-end translation from SQL.
The text was updated successfully, but these errors were encountered: