-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Parsing fails if quoted table name is a reserved word (prepared statement) #10739
Comments
@findepi It seems that the output of formatter forgets double quotes and the parser fails when it tries to parse the formatted sql.
This would have a side effect that in show create table the names would come as double quoted even if they do not overlap with keywords. |
One solution is to capture the quoted identifier in the
@findepi Your insights on this ? |
It's not just reserved words, but it would seem if any component contain a dash, this same error occurs. Sample class (using
Simply changing |
@jeff303 Presto 3xx releases (now called Trino) are maintained at https://github.com/trinodb/trino. |
Thanks for the pointer. Unfortunately, in this particular case, I need to work with a cluster using the Presto client protocol, as opposed to the Trino client protocol (which are not compatible as per here). I'll find a way to work around this issue. |
Updating Presto instance to have SSL enabled (in addition to HTTP/insecure) Adding versions of every catalog that have "-" replaced with "_" due to a bug in the Presto JDBC driver (prestodb/presto#10739) Exposing SSL port from Docker image Adding convenient build script
Cherry-pick of trinodb/trino#80 Presto doesn't maintain the quotedness of an identifier when using SqlQueryFormatter so it results in throwing parsing error when we run prepare query of the syntax [prestodb#10739]. This PR solves that above issue. Co-authored-by: praveenkrishna <[email protected]>
Cherry-pick of trinodb/trino#80 Presto doesn't maintain the quotedness of an identifier when using SqlQueryFormatter so it results in throwing parsing error when we run prepare query of the syntax [#10739]. This PR solves that above issue. Co-authored-by: praveenkrishna <[email protected]>
I initially encountered the following issue using prestodb version 0.193 in a docker container. I have verified the issue is still present in version 0.203. The remote database is PostgreSQL 9.6 so I am using the PostgreSQL connector.
Using presto-cli to run a prepare statement where the query contains a reserved word as a table name returns a parsing error. Running the same statement with another character added onto the table name (even if it isn't a valid table in the remote database) so it is no longer a reserved word, works.
For example:
PREPARE stmt0 FROM SELECT id FROM "public"."case";
returns
Adding another character to the table name does not return the error:
PREPARE stmt0 FROM SELECT id FROM "public"."case2";
returns
PREPARE
.The text was updated successfully, but these errors were encountered: