Skip to content

Conversation

@ANeumann82
Copy link
Contributor

No description provided.

Copy link
Contributor

@manticore-projects manticore-projects left a comment

Choose a reason for hiding this comment

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

Great work and I do appreciate your effort and dedication. Thank you much!
A few small concerns though, nothing severe just the normal German nit-picking.

Kudos and cheers!

| <#TYPE_REAL: "REAL" | "FLOAT4" | "FLOAT">
| <#TYPE_DOUBLE: "DOUBLE" | "PRECISION" | "FLOAT8" | "FLOAT64">
| <#TYPE_VARCHAR: "NVARCHAR" | "VARCHAR" | "NCHAR" | <K_CHAR> | "BPCHAR" | "TEXT" | "STRING" | <K_CHARACTER> | "VARYING">
| <#TYPE_VARCHAR2: <K_VARCHAR2>>
Copy link
Contributor

Choose a reason for hiding this comment

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

This should got to TYPE_VARCHAR since we try to establish a reasonable grouping please.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that was left over from me figuring it out

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a problem. When I move this into the TYPE_VARCHAR, the generated TokenManager gets a code too large. I guess we're reaching the limits of JavaCC again...

I'll have to look into why exactly this happens, but I've not applied this change yet in my last commit.

@ANeumann82
Copy link
Contributor Author

Great work and I do appreciate your effort and dedication. Thank you much! A few small concerns though, nothing severe just the normal German nit-picking.

Kudos and cheers!

Keep the nit-picking coming :) There's still some features missing before I'll consider this PR ready for merge.

@bhupi26
Copy link

bhupi26 commented Oct 31, 2025

_ No description provided. _

@ANeumann82 Great Work!! Can you please let me know the ETA for this change

@manticore-projects
Copy link
Contributor

@ANeumann82: How can we move this forward together? What assistance can I provide please?

# Conflicts:
#	src/main/java/net/sf/jsqlparser/util/deparser/ExpressionDeParser.java
#	src/main/jjtree/net/sf/jsqlparser/parser/JSqlParserCC.jjt
@ANeumann82
Copy link
Contributor Author

@manticore-projects Sorry for the long silence. I've been into a rabbit hole of JavaCC and other parsers...

I've updated the PR from the master branch, but now I get "code too large" in the generated "CCJsqlParserTokenManager.java".

Do you have any idea to work around that problem?

I don't know if there's anything we can do about that with the current JavaCC version. I'm currently looking into alternative parsers to maybe replace JavaCC in JSQLParser at some point, but that's not easy.

@manticore-projects
Copy link
Contributor

@manticore-projects Sorry for the long silence. I've been into a rabbit hole of JavaCC and other parsers...

Have done that, have been there and you are welcome.
(I needed a proper SQL panel for our ETL Software, which made me dive into JSQLFormatter, which made me dive into JSQLParser, which made me dive into JavaCC -- and all I wanted was to move some data for our clients.)

I've updated the PR from the master branch, but now I get "code too large" in the generated "CCJsqlParserTokenManager.java".

I will lodge a case with the JavaCC team, maybe they can help.

Do you have any idea to work around that problem?

We have too many token apparently. I want to check first if the JavaCC team can help.
Otherwise we need to refactor the Grammar and avoid any useless token that is used not more than one time and in too specific productions only. I have had a deep discussion on that with the JavaCC team before on this topic.

I don't know if there's anything we can do about that with the current JavaCC version. I'm currently looking into alternative parsers to maybe replace JavaCC in JSQLParser at some point, but that's not easy.

I am most interested in this one too and dug deep already. Unfortunately there is not really any good alternative, but maybe CongoCC. Unfortunately there are some social issues around this project (or maybe with me). And also there still seems to be a (small?) performance penalty in the generated parser.

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