GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — feat: add support SELECT all columns from function result by 0xlianhu · Pull Request #2207 · JSQLParser/JSqlParser

Conversation

@0xlianhu

@0xlianhu 0xlianhu commented Mar 26, 2025 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

PostgreSQL supports composite type expansion using .*, for example, below query is valid in PostgreSQL:

SELECT (pg_stat_file('postgresql.conf')).*

More generic one is like below one in queries or sub-queries:

SELECT (function_name(param1, ... paramN)).* FROM my_table ...

There might be multiple duplicated parentheses surround the function call, such as:

SELECT (((pg_stat_file('postgresql.conf')))).* -- this is same effect as one `()` surrounding

The PR is adding the support to parse/deparse this type of SQLs.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Lian Hu
feat: add support SELECT all columns from function result
2656350
PostgreSQL supports composite type expansion using .*,
for example below query is valid in PostgreSQL:
SELECT (pg_stat_file('postgresql.conf')).*
@manticore-projects

manticore-projects commented Mar 26, 2025

Copy link
Copy Markdown
Contributor

Beautifully executed! Well done and thank you much for your effort and contribution.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@manticore-projects
manticore-projects merged commit 30cf5d7 into JSQLParser:master Mar 26, 2025
@manticore-projects

manticore-projects commented May 13, 2025

Copy link
Copy Markdown
Contributor

Greetings!

Unfortunately, I found out that commit 30cf5d7 causes a huge performance deterioration:

(version)  Mode  Cnt    Score    Error  Units
   latest  avgt    3   81.637 ± 21.386  ms/op <-- `FunctionAllColumns()` commented out
      5.2  avgt    3  393.523 ± 54.199  ms/op <-- release w/ `FunctionAllColumns()`
      5.1  avgt    3   86.419 ± 22.178  ms/op <-- release w/o `FunctionAllColumns()`

This toll is not acceptable for a rather exotic feature only and I am going to disable it.
Although all code is still there and only the call of FunctionAllColumns() in PrimaryExpression has been commented out.

You are welcome to refactor your code and I will most happily accept it again once performance can be proved.

Recommendations:

  1. try to avoid the syntactic Lookahead
  2. your (((( FUNCTION )))).* is nothing else but a ParenthesedExpressionList with just one parameter of type Function, followed by ".". So maybe parse for a possible extension by "." at the end of a ParenthesedExpressionList when it has only one single Function element.

I am open for discussion of course.
Best and cheers!

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

manticore-projects added a commit that referenced this pull request May 13, 2025
@manticore-projects
feat: Optimise performance
7d42ff6
- optimise the `LOOKAHEAD`, avoid syntactic lookaheads

- disable `FunctionAllColumns()` in `PrimaryExpression` related to #2207

Signed-off-by: Andreas Reichel <[email protected]>
@fudianchn fudianchn mentioned this pull request Aug 13, 2026
fix: support PostgreSQL composite row expansion (function()).* #2463
Merged
manticore-projects pushed a commit that referenced this pull request Aug 13, 2026
@fudianchn
fix: support PostgreSQL composite row expansion (function()).* (#2463)
7ced34d
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]>
@fudianchn fudianchn mentioned this pull request Aug 31, 2026
[BUG] Parse time grows super-linearly on long dotted-name chains and nested parentheses (phase-2 lookahead), StackOverflowError at nesting depth ~2000 #2519
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

2 participants

@0xlianhu @manticore-projects
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.