GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||
GeezerVison is showing github.com — feat: add support SELECT all columns from function result by 0xlianhu · Pull Request #2207 · JSQLParser/JSqlParser Conversation
|
|
Beautifully executed! Well done and thank you much for your effort and contribution. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Greetings! Unfortunately, I found out that commit 30cf5d7 causes a huge performance deterioration: This toll is not acceptable for a rather exotic feature only and I am going to disable it. You are welcome to refactor your code and I will most happily accept it again once performance can be proved. Recommendations:
I am open for discussion of course. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
- optimise the `LOOKAHEAD`, avoid syntactic lookaheads - disable `FunctionAllColumns()` in `PrimaryExpression` related to #2207 Signed-off-by: Andreas Reichel <[email protected]>
PostgreSQL expands a composite-returning function call into its columns with (function_call).*, e.g. SELECT (json_populate_record(NULL::users, data)).* FROM staging_users. JSQLParser rejected the trailing .* . Composite row expansion was implemented in #2207 but afterwards disabled, because the speculative syntactic LOOKAHEAD(FunctionAllColumns()) at the PrimaryExpression entry caused a severe regression (393 ms/op vs ~86 ms/op). The AST node, deparser, validator and all visitors stayed in place; only the grammar call site was commented out. Re-enable the feature without the speculative lookahead: after a ParenthesedExpressionList wrapping a single Function is parsed, a bounded semantic follower check (isFunctionAllColumnsAhead) peeks .* and wraps the result into FunctionAllColumns. The check first compares the next two tokens and only then unwraps the already-parsed expression, so the common path (a parenthesised expression not followed by .*) bails out in two comparisons without any speculative production or backtracking. TablesNamesFinder now descends into the wrapped function so column/table references inside the expansion are not lost. Scope: only (function_call).* is supported; arbitrary (non-function expression).* remains unsupported and fails cleanly as before. Redundant surrounding parentheses are unwrapped to the inner function. Performance (gradle jmh, parseSQLStatements on performance.sql, version=latest, 10 forks x 10 iterations, 100 samples, dedicated 32-core host): master (disabled): 3.632 +/- 0.020 ms/op this change: 3.639 +/- 0.023 ms/op The +0.19% delta lies within the confidence intervals and is far from the 393 ms/op toll that motivated disabling the feature. Testing: CompositeRowExpansionTest covers the issue case, simple and no-arg functions, the INSERT...SELECT use case, multiple surrounding parentheses, and negative cases (no trailing .*, RowGet expression, non-function expression). The positive tests fail on master and pass with this change. Fixes #2412 Signed-off-by: 付典 <[email protected]>
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.