Skip to content

parse_functions: find functions inside FROM-clause subqueries, joins and table-function arguments - #17

Open
asubbarao wants to merge 3 commits into
hotdata-dev:mainfrom
asubbarao:fix/parse-functions-from-subqueries
Open

asubbarao wants to merge 3 commits into
hotdata-dev:mainfrom
asubbarao:fix/parse-functions-from-subqueries

Conversation

@asubbarao

Copy link
Copy Markdown

parse_function_names and parse_functions skip everything in the FROM clause: subqueries, both sides of a join, and table-function arguments, as well as scalar subqueries. The community build (parser_tools pinned at 6a94f2b) returns [] for the first query below.

SELECT parse_function_names('SELECT * FROM (SELECT avg(n) AS a FROM range(5) t(n)) s');
-- before: []    after: [avg]

The traversal now descends into from_table (join sides and conditions, subquery references, table-function arguments and subqueries) and into SubqueryExpression, following the same table-reference pattern parse_tables uses.

query before after
FROM (SELECT avg(n) …) s [] [avg]
FROM (SELECT upper(x) …) a JOIN (SELECT lower(y) …) b [] [upper, lower]
FROM range(abs(-5)) [] [abs]
SELECT (SELECT sum(1)) WHERE x IN (SELECT length(z) …) [] [sum, length]

Verified against DuckDB v1.4.4 (this repo's pin): the four cases are added to both parse_function_names.test and parse_functions.test. On the unpatched source both files fail ([] <> [avg], 2 of 11 test cases); with the patch all 11 test cases pass.

🤖 Generated with Claude Code

@asubbarao

Copy link
Copy Markdown
Author

The red Windows job here is not from this change: windows_amd64 has been red on main since 2026-07-20, because windows-latest moved to the VS 2026 image and extension-ci-tools v1.4.4 falls back to MinGW there. The fix is in #18. Once that merges I'll rebase this PR onto it.

extension-ci-tools <= v1.5.x defines TEST_PATH with baked-in quotes
(TEST_PATH="/test/unittest"), so 'make test_release' invokes
./build/release/"/test/unittest", which fails with Error 127 on
Windows (Git Bash) before the test binary ever runs. Fixed upstream
in v2.0-cyanoptera via the RUN_TEST macro; override
test_release_internal here until ci_tools can move past v1.5.x.
Identical to the stock recipe on POSIX.
The extension-ci-tools workflow hardcodes vcvars64.bat under
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise", which no
longer exists on current windows-latest runners. The call fails with "The
system cannot find the path specified", CMake then silently falls back to
a stray GCC 15.2.0, and the resulting unittest binary cannot be launched
from Git Bash (Error 127, deterministic across the 2026-09-24 and
2026-10-04 runs). This was misdiagnosed earlier as a test-harness quoting
bug; the invoked command line is byte-identical on the passing mingw job.

Set SKIP_TESTS=1 for windows_amd64 (before the ci-tools include, which
reads it at include time) until upstream fixes the VS path. Windows
coverage is retained via windows_amd64_mingw, where the full suite
(11 tests / 435 assertions) passes.
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.

2 participants