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
{{ message }}
Repository navigation
[BUG] JSQLParser 5.1: PostgreSQL: fail to parse dollar-quoted string constants with tags #2233
@E1izabeth: I dived deep into this issue and unfortunately I can not offer much hope here:
I am quite sure, that this was never supported before. It just failed faster when not even "Dollar quotes w/o Tags" were supported
while I can offer some remedy for parsing "Dollar quotes w/ Tags" it will never work perfectly because of white space:
-- this worksselect $tag$this is a test $tag$
-- this works but alters the contentselect $tag$this
is
a
test
$tag$
So the statement will be parsed and return the correct AST. But content of the String Value can't be guaranteed.
Unfortunately there is nothing I can do, because JavaCC mangles the white spaces and returns only token streams.
This gets us back to item 1) It never worked but failed faster.
It looks to me like you are not calling the parser supervised (obeying the timeout) and I would like to encourage you again to look into this. We will always have some Freezing Statements and the supervised execution terminates those reliably and efficiently without disturbing the user experience.
$tag$this is a test$tag$ collides with (currently) allowed identifiers $tag$this (because we allow identifiers to start with and contain a $)
the solution would be to tighten identifiers so they either start with a $ (and then don't contain any following $) or they contain a $ only when they don't start with a $
though adding such an additional rule breaks the JavaCC7 parser generator: error: code too large for try statement
We are using too many tokens and are pretty much at the end of JavaCC 7 here and I will have to test/decide if switching to JavaCC 8 or CongoCC can solve this challenge. That would be a "next version" though, after releasing the current JSQLParser 5.2.
So what are our possible instant options here:
a) this has never worked before, but just failed instantly while now it hangs (based on support of $$...$$ blocks)
--> I can help you by showing how to run JSQLParser supervised so it will fail within definable timeout.
This should be done anyway since also other complex statements can freeze.
b) or I can provide a DBeaver branch temporarily, where we switch off identifiers containing $ (which is not SQL:2016 complaint)
If you have any better idea, please do let me know.
Best and cheers!
I have started a JavaCC 8 based development branch and I can confirm that JavaCC 8 lift the restrictions on defining tokens and allows us to expand the grammar.
This will allow us to incorporate the Dollar-quoted tags above, tests have been positive.
Unfortunately, some of the Token internals have changed and right now rewriting of Tokens (used for T-SQL bracket-quoting and advanced escaping) does not work.
So all of this will need extra work and will take some time, but I won't give up on it.
- b) or I can provide a DBeaver branch temporarily, where we switch off identifiers containing $ (which is not SQL:2016 complaint) - For option b), I have to discuss it with a team.
It would be great if you could provide us with any branch or snapshot when it becomes possible.
Sure, I am down to 54 failing tests out of 2,900 tests in total.
I am eliminating some of the exotic stuff as we speak and then will provide you with a drop-in replacement asap.
I have fixed a massive performance regression in released JSQLParser-5.2 and have added proper JHM benchmarks for avoiding just mischief in the future.
...does not - upon clicking on the count rows icon in DBeaver, I'm getting "Can't count rows for non-SELECT queries", which seems to indicate a parsing failure.
Activity
manticore-projects commentedon Apr 29, 2025
@E1izabeth: thank you for reporting, I will look into this asap.
manticore-projects commentedon May 1, 2025
Greetings.
"Dollar quoting" is actually supported and the following works:
What is missing is the support for the "optional tag" and I do wonder if this ever has worked (not arguing though).
So I will have to look for a solution to extend this token.
E1izabeth commentedon May 1, 2025
Thanks
manticore-projects commentedon May 1, 2025
@E1izabeth: I dived deep into this issue and unfortunately I can not offer much hope here:
So the statement will be parsed and return the correct AST. But content of the String Value can't be guaranteed.
Unfortunately there is nothing I can do, because JavaCC mangles the white spaces and returns only token streams.
This gets us back to item 1) It never worked but failed faster.
It looks to me like you are not calling the parser supervised (obeying the timeout) and I would like to encourage you again to look into this. We will always have some
Freezing Statementsand the supervised execution terminates those reliably and efficiently without disturbing the user experience.Best and cheers!
E1izabeth commentedon May 1, 2025
@manticore-projects thank you so much for your effort and responsiveness
manticore-projects commentedon May 1, 2025
I am still fighting to get this white space right ...
manticore-projects commentedon May 1, 2025
How cool is this one:
Now, unfortunately I am battling with some collisions with other valid syntax, mainly
$parameter. But I am confident getting this solved somehow soon.manticore-projects commentedon May 2, 2025
@E1izabeth:
Unfortunately I have only bad news:
$tag$this is a test$tag$collides with (currently) allowed identifiers$tag$this(because we allow identifiers to start with and contain a$)the solution would be to tighten identifiers so they either start with a
$(and then don't contain any following$) or they contain a$only when they don't start with a$though adding such an additional rule breaks the JavaCC7 parser generator:
error: code too large for try statementWe are using too many tokens and are pretty much at the end of JavaCC 7 here and I will have to test/decide if switching to JavaCC 8 or CongoCC can solve this challenge. That would be a "next version" though, after releasing the current JSQLParser 5.2.
So what are our possible instant options here:
a) this has never worked before, but just failed instantly while now it hangs (based on support of
$$...$$blocks)--> I can help you by showing how to run JSQLParser supervised so it will fail within definable timeout.
This should be done anyway since also other complex statements can freeze.
b) or I can provide a
DBeaverbranch temporarily, where we switch off identifiers containing$(which is not SQL:2016 complaint)If you have any better idea, please do let me know.
Best and cheers!
E1izabeth commentedon May 2, 2025
I see. Thank you.
For option
a), you're proposing to add.withTimeOut(..)parameter for the parser, right?We have configured this way right now:
For option
b), I have to discuss it with a team.manticore-projects commentedon May 2, 2025
On 1)
Or simply:
E1izabeth commentedon May 2, 2025
Thank you! We'll modify according to your suggestions.
manticore-projects commentedon May 3, 2025
Greetings @E1izabeth
I have started a JavaCC 8 based development branch and I can confirm that JavaCC 8 lift the restrictions on defining tokens and allows us to expand the grammar.
This will allow us to incorporate the Dollar-quoted tags above, tests have been positive.
Unfortunately, some of the Token internals have changed and right now rewriting of Tokens (used for T-SQL bracket-quoting and advanced escaping) does not work.
So all of this will need extra work and will take some time, but I won't give up on it.
E1izabeth commentedon May 5, 2025
Hi, @manticore-projects!
Thanks for the update.
It would be great if you could provide us with any branch or snapshot when it becomes possible.
manticore-projects commentedon May 5, 2025
Sure, I am down to 54 failing tests out of 2,900 tests in total.
I am eliminating some of the exotic stuff as we speak and then will provide you with a drop-in replacement asap.
JavaCC 8 based branch: https://github.com/JSQLParser/JSqlParser/tree/javacc8
E1izabeth commentedon May 5, 2025
Thanks
manticore-projects commentedon May 5, 2025
DBeaver licenses are welcome :-)
manticore-projects commentedon May 13, 2025
@E1izabeth Compliments!
I have fixed a massive performance regression in released JSQLParser-5.2 and have added proper JHM benchmarks for avoiding just mischief in the future.
Please see https://github.com/JSQLParser/JSqlParser#performance
You can use JSQLParser-5.3 Snapshot as a drop-in hotfix. It does not change anything except performance and is fully compatible.
I will work in parallel on releasing a hotfix asap but its NOT in my control.
Any questions or concerns, please just ask.
E1izabeth commentedon May 13, 2025
Thank you!
arhayka commentedon Jun 11, 2025
Hello @manticore-projects! We appreciate your support and want to offer you a compliment. Please write to anna.pozdeeva@dbeaver.com and provide your nickname in GitHub.
brankoradovanovic-mcom commentedon Sep 4, 2026
Indeed it does, at least from DBeaver, but this (note additional dollar sign):
...does not - upon clicking on the count rows icon in DBeaver, I'm getting "Can't count rows for non-SELECT queries", which seems to indicate a parsing failure.