Skip to content

Conversation

@srielau
Copy link
Contributor

@srielau srielau commented Dec 22, 2025

What changes were proposed in this pull request?

  • Allow reference of built in functions with qualifiers builtin or system.builtin and temporary functions as session or system.session.
  • Cleaned up APIs to resolve functions to prep for configurable path
  • Register builtin and session fucntions with qualified names, so they can co-exist
  • Fix a bug that allowed session functions with the same name to co-exist as table and scalar functions
    FUNCTION_RESOLUTION_DESIGN.md

Why are the changes needed?

This portion of work allows users to expclicitly pick a builtin or temporary fucntion, teh same way they would pick a persisted function by fully qualifying it.
This increases security.

In follow on work we plan to allow the priority of function resolution to be configurable, for example to push temporary functions after built-ins or even after persisted functions.
Ultimately we aim for proper SQL Standard PATH support where a user can add "libraries" of functions to the path.

Does this PR introduce any user-facing change?

You can now reference builtin functions such as concat with builtin.concat or system.builtin.concat. Teh same for temporary functions which can be qualified as session, or system.session.

How was this patch tested?

A new suite: functionQualificationSuite.scala has been added

Was this patch authored or co-authored using generative AI tooling?

Yes: Claude Sonnet

@github-actions github-actions bot added the SQL label Dec 22, 2025
- Persistent functions now cached with unqualified keys for compatibility
- Temporary functions use composite keys (session.funcName)
- Both can coexist in the same registry
- Views correctly exclude temp functions from resolution

Issue: View test still failing - needs investigation into function builder resolution
- Persistent functions now stored with qualified keys (catalog.db.func)
- Prevents conflicts when multiple databases have same function name
- Temporary functions still use composite keys (session.func)

Known issues:
- View function resolution test still failing
- Possible function listing regressions to investigate
Added extensive debug logging to understand why views capture
wrong function class. Ready for detailed tracing.
**THE BUG:**
In resolveBuiltinOrTempFunctionInternal, the 'isBuiltin' parameter was
incorrectly checking if the temp/builtin identifier existed in the
session registry, instead of checking the static FunctionRegistry.builtin.

This caused lookupTempFuncWithViewContext to treat temp functions as
builtins, bypassing view context checks and allowing temp functions
created AFTER a view to incorrectly shadow the persistent function
that the view should use.

**THE FIX:**
Changed the isBuiltin check to use FunctionRegistry.builtin.functionExists
and TableFunctionRegistry.builtin.functionExists directly, matching
master's behavior.

**TEST RESULTS:**
✅ All 62 tests pass (PersistedViewTestSuite + FunctionQualificationSuite)
✅ SPARK-33692 view test now passes
✅ View correctly uses MyDoubleAvg and ignores temp MyDoubleSum
Removed leftover test scripts that were causing compilation errors:
- test_simple_function.scala
- test_view_function.scala

All code now compiles cleanly.
Analysis covers:
- Complete API surface (read/write operations)
- Current architecture and memory usage
- Three proposed optimization approaches
- Detailed feasibility assessment

KEY DISCOVERY: Internal functions already use separate static registry!
- FunctionRegistry.internal contains ~20 ML/Pandas/Connect functions
- Resolved directly, bypassing SessionCatalog
- Proves composite registry pattern works in production
- Validates proposed optimization approach

Memory savings potential: 98% reduction for high-session deployments
Implementation effort: 2-3 days coding + testing
Risk: Low (pattern already proven with internal functions)
Comprehensive comparison covering:
- Registry architecture (cloned vs static)
- User-facing vs implementation details
- Resolution paths and shadowing behavior
- Examples and use cases
- Historical context (Spark 4 separation)

KEY FINDINGS:
- Builtin: ~500 user-facing SQL functions, cloned per session
- Internal: ~20 implementation functions for Connect/ML/Pandas, single global registry
- Internal functions already use separate static registry pattern
- Proves composite registry approach is production-ready

This validates our proposed optimization approach for builtins.
Updated test to expect INVALID_TEMP_OBJ_QUALIFIER (AnalysisException)
instead of INVALID_SQL_SYNTAX.CREATE_TEMP_FUNC_WITH_DATABASE (ParseException)
for invalid temporary function qualifications.

This aligns with the user's request to treat invalid temp function
qualifications as semantic errors (42602 SQLSTATE) rather than
syntax errors.

Test cases updated:
- CREATE TEMPORARY FUNCTION a.b() - now expects INVALID_TEMP_OBJ_QUALIFIER
- CREATE TEMPORARY FUNCTION a.b.c() - now expects INVALID_TEMP_OBJ_QUALIFIER

All tests pass.
These files were working notes created during development and should
not be committed to the repository:
- BUILTIN_VS_INTERNAL_FUNCTIONS.md
- CURSOR_IMPLEMENTATION_SUMMARY.md
- CURSOR_TEST_RESULTS.md
- FUNCTION_QUALIFICATION_ANALYSIS.md
- FUNCTION_QUALIFICATION_COMPLETE.md
- FUNCTION_QUALIFICATION_SUMMARY.md
- FUNCTION_REGISTRY_API_ANALYSIS.md
- IMPLEMENTATION_COMPLETE.md
- TABLE_FUNCTION_REGISTRY_ANALYSIS.md
- UNIFIED_FUNCTION_NAMESPACE.md

Only production code and tests should be in the repository.
These were working test files created during development:
- test_both.sql
- test_namespace.sql
- test_range.sql

They should not be committed to the repository.
…apsulation

Refactoring #1: Extract Scalar/Table Function Duplication
- Added handleViewContext() helper to centralize view resolution logic
- Added lookupFunctionWithShadowing() generic helper for both scalar and table functions
- Eliminated ~50 lines of duplicated shadowing and view context logic
- Simplified lookupBuiltinOrTempFunction() and lookupBuiltinOrTempTableFunction()

Refactoring apache#2: Unified Qualification Checker
- Added isQualifiedWithNamespace() helper to check namespace qualifications
- Refactored maybeBuiltinFunctionName() and maybeTempFunctionName() to use common helper
- Eliminated ~15 lines of duplication
- Prepares for future PATH implementation

Documentation Improvements:
- Added comprehensive scaladoc to TEMP_FUNCTION_DB explaining composite key pattern
- Added scaladoc to tempFunctionIdentifier() and isTempFunctionIdentifier()
- Added detailed comments to new helper methods

Benefits:
- Single source of truth for shadowing logic
- Easier to maintain and test
- Better encapsulation of view resolution context
- More consistent code structure

All tests pass:
- FunctionQualificationSuite: 24/24 tests passed
- SessionCatalogSuite: 100/100 tests passed
Naming Improvements:
- Renamed 'useTempIdentifier' → 'lookupAsTemporary' for clarity
- More semantic boolean parameter names

Code Quality:
- Made handleViewContext() functional (removed imperative 'return')
- Removed unused 'tempIdentifier' and 'builtinIdentifier' variables
- Extracted resolveFunctionWithFallback() to eliminate duplication
- Used Option.filter for more idiomatic Scala

Benefits:
- More functional programming style
- Clearer intent with better parameter names
- No unused variables cluttering the code
- Extracted common pattern reduces duplication by ~30 lines
- More readable and maintainable

All 24 tests in FunctionQualificationSuite pass.
Removed sql-function-qualifiers.sql and its golden files.
All test coverage is comprehensively provided by FunctionQualificationSuite.scala.

Rationale:
- Eliminates duplication between SQL and Scala tests
- Scala tests provide better error validation with checkError()
- Scala tests are easier to maintain and debug
- Scala tests have better test isolation
- No loss of coverage: Scala suite has 24 tests covering all scenarios

FunctionQualificationSuite.scala provides complete coverage:
- 8 tests: Reference qualification (SELECT statements)
- 9 tests: DDL (CREATE/DROP TEMPORARY FUNCTION)
- 4 tests: Type mismatch errors
- 3 tests: Integration scenarios

All 24 tests pass.
Moved private helper functions (isQualifiedWithNamespace, maybeBuiltinFunctionName,
maybeTempFunctionName) after the public methods that use them for better readability.
…aryFunction

The method returns a boolean indicating whether a function is builtin/temporary,
so the name should follow Scala boolean method naming conventions.
…on validation

Split isBuiltinOrTemporaryFunction into two methods:
1. isBuiltinOrTemporaryFunction: Pure boolean method, no side effects
2. validateFunctionExistence: Validation method that throws errors

This separates concerns and makes the code organization clearer.
…mbiguation

Added comprehensive SQL test file (function-qualification.sql) that tests:
- Builtin function qualification (system.builtin.func, builtin.func)
- Temporary function qualification (system.session.func, session.func)
- Temporary functions shadowing builtins
- Builtin functions accessible with qualification when shadowed
- Case insensitivity of qualifications
- Error cases (invalid qualifications, cannot drop builtin, etc.)
- DESCRIBE FUNCTION with qualified names
- Table functions with qualified names
- Cross-type shadowing
- CREATE OR REPLACE with qualified names
- IF NOT EXISTS with qualified names

This provides comprehensive end-to-end testing of the qualified function name
feature through golden file tests.
Removed the Scala test suite (FunctionQualificationSuite.scala) and converted
all tests to SQL golden file format. The enhanced function-qualification.sql now includes:

- All basic qualification tests (builtin/session namespaces)
- Shadowing behavior (temp shadows builtin, builtin accessible when qualified)
- Cross-type error detection (scalar in table context, table in scalar context)
- Generator functions (work in both contexts)
- DDL operations (CREATE/DROP with qualified names, OR REPLACE, IF NOT EXISTS)
- View resolution with temporary functions
- Multiple functions in queries
- Aggregate functions with qualified names
- Error cases (non-existent, invalid qualifications, type mismatches)
- DESCRIBE and SHOW FUNCTIONS with qualified names

Total: 32 comprehensive test scenarios covering all functionality.

This makes the tests easier to maintain and provides better end-to-end coverage.
Reorganized function-qualification.sql with:
- Clear section organization (9 sections)
- Removed duplicate tests (was testing shadowing 3+ times)
- Grouped related tests together
- Better test progression (simple -> complex)

Sections:
1. Basic Qualification Tests
2. Temporary Function Creation and Qualification
3. Shadowing Behavior
4. Cross-Type Shadowing (Scalar vs Table)
5. Cross-Type Error Detection
6. DDL Operations with Qualified Names
7. Error Cases
8. Views with Temporary Functions
9. Multiple Functions in Single Query

Result: More maintainable, easier to understand, full coverage with no redundancy.
Resolved conflicts in:
- QueryCompilationErrors.scala: Kept invalidTempObjQualifierError and accepted upstream signature change for cannotRefreshBuiltInFuncError
- SparkSqlParser.scala: Kept extractTempFunctionName logic for qualified temporary function names
- DDLParserSuite.scala: Kept UnresolvedFunctionName import
Address reviewer feedback to separate lookup logic from error throwing.

Changes:
- Introduced FunctionType enum (Builtin, Temporary, Persistent, TableOnly, NotFound)
- Added lookupFunctionType() method that only performs lookup and classification
- Moved error throwing logic from FunctionResolution to Analyzer (the caller)
- Simplified isBuiltinOrTemporaryFunction() to use lookupFunctionType()
- Eliminated duplicate lookups in LookupFunctions rule

Benefits:
- Cleaner separation of concerns (lookup vs validation)
- Single source of truth for function type determination
- No more methods that return boolean AND throw errors
- More efficient - no redundant lookups
The DESCRIBE FUNCTION output for temporary functions includes a
non-deterministic 'createTime' timestamp field, causing test flakiness.

Removed DESCRIBE tests for temporary functions (desc_test) and kept
only the stable DESCRIBE tests for builtin functions (which don't have
timestamps in their output).

This ensures the function-qualification.sql test is deterministic and
can run reliably in CI.
The test was failing because we were calling lookupFunction twice:
1. Once in lookupBuiltinOrTempFunction()
2. Again in isTemporaryFunction() (which calls functionExists -> lookupFunction)

Solution: After calling lookupBuiltinOrTempFunction (which does a single
efficient lookup with shadowing logic), determine if it's temp or builtin
by checking the ExpressionInfo's database field rather than calling
isTemporaryFunction. Temp functions have database=SESSION_NAMESPACE.

This reduces lookups from 4 to 2 for two calls to the same function,
fixing the test expectation and improving performance.
Internal functions (like unwrap_udt) were not being found because
lookupFunctionType was calling v1SessionCatalog.lookupBuiltinOrTempFunction
directly, which bypasses the internal function check in
FunctionResolution.lookupBuiltinOrTempFunction.

Fixed by calling FunctionResolution's lookupBuiltinOrTempFunction(nameParts, node)
which properly handles internal functions when node.isInternal is true.

Internal functions are treated as Builtin type for classification purposes.
The golden output files were out of sync with the input SQL file
after we removed the DESCRIBE FUNCTION tests for temporary functions
(which had non-deterministic timestamps).

Regenerated both:
- analyzer-results/function-qualification.sql.out
- results/function-qualification.sql.out

Removed 46 lines corresponding to the removed desc_test queries.
Fixes issue where analyzer rules that check for specific function names
(like COUNT(*) expansion) were only checking for unqualified names.

This allows users to call builtin functions with qualified names:
- builtin.count(*) → works now
- system.builtin.count(*) → works now
- BUILTIN.COUNT(*) → works now (case insensitive)

Changes:
1. Analyzer.scala:
   - Added matchesFunctionName() helper to check function names regardless
     of qualification
   - Updated expandStarExpression() to use matchesFunctionName() instead of
     exact Seq("count") match
   - Preserves original qualification in transformed nodes (no longer
     rewrites to unqualified "count")
   - Handles both count(*) → count(1) expansion and count(tbl.*) blocking

2. FunctionResolver.scala (resolver package):
   - Updated isCount() to use nameParts.lastOption instead of requiring
     nameParts.length == 1
   - Updated normalizeCountExpression() to preserve original nameParts
   - Removed unused Locale import

3. Added comprehensive tests in function-qualification.sql:
   - Tests qualified count(*) with builtin.count(*) and
     system.builtin.count(*)
   - Tests case insensitivity (BUILTIN.COUNT(*))
   - Tests count(tbl.*) blocking with qualified names
   - Regenerated golden files

This addresses reviewer feedback about supporting qualified names
throughout the analyzer, not just in resolution.
ResolverGuard.checkUnresolvedFunction was checking that
nameParts.size == 1, which prevented the single-pass analyzer
from being used when builtin functions were called with qualified
names (e.g., builtin.abs, system.builtin.count).

Changes:
- Removed nameParts.size == 1 requirement
- Added proper validation to only accept:
  * Unqualified builtin: count()
  * Qualified builtin: builtin.count(), system.builtin.count()
- Rejects session/temporary functions (session.func) as they are UDFs
- Rejects persistent functions (catalog.db.func) from external catalogs
- Changed from nameParts.head to nameParts.last to extract function name
- Updated comments to clarify qualified name support

This allows the single-pass analyzer to handle queries like:
- SELECT builtin.abs(-5)
- SELECT system.builtin.count(*)
- SELECT BUILTIN.UPPER('hello')

But correctly rejects:
- SELECT session.my_func() (temporary function - UDF)
- SELECT my_catalog.my_db.func() (persistent function - external)

The check still correctly validates:
1. Function is not in UNSUPPORTED_FUNCTION_NAMES list
2. Function exists in FunctionRegistry.functionSet (built-ins only)
3. All children expressions are supported

This completes the qualified function name support for builtin
functions across all analyzer components.
Reviewer (gengliangwang) correctly identified that the isCount check
would incorrectly accept "foo.bar.count()" where foo.bar could be
a catalog.database (persistent function), not the builtin count.

This is the same issue we fixed in ResolverGuard - need to validate
the entire qualified name, not just the last part.

Changes:
- Replaced simple lastOption check with comprehensive validation
- Now only accepts:
  * Unqualified: "count"
  * Builtin qualified: "builtin.count"
  * Full builtin: "system.builtin.count"
- Rejects:
  * catalog.db.count (persistent function)
  * session.count (temporary function)
  * Any other qualification pattern

This ensures COUNT(*) normalization only applies to the actual
builtin count function, not to user-defined persistent functions
that happen to be named "count".

Added CatalogManager import for BUILTIN_NAMESPACE and
SYSTEM_CATALOG_NAME constants.
Reviewer (gengliangwang) correctly identified two issues in the
DropFunctionCommand temporary function namespace validation:

1. Redundant check: CatalogManager.SESSION_NAMESPACE is literally
   "session", so checking both was unnecessary
2. Case sensitivity: The check was case-sensitive, inconsistent
   with all other namespace checks in the codebase

Changes:
- Removed redundant hardcoded "session" string check
- Changed from case-sensitive (!=) to case-insensitive
  (equalsIgnoreCase) comparison
- Updated comment to note case-insensitivity

This makes the behavior consistent with:
- SparkSqlParser.extractTempFunctionName (case-insensitive)
- FunctionResolution helper methods (case-insensitive)
- FunctionResolver.isCount (case-insensitive)
- ResolverGuard.checkUnresolvedFunction (case-insensitive)

Now correctly handles:
- DROP TEMPORARY FUNCTION session.my_func
- DROP TEMPORARY FUNCTION SESSION.my_func
- DROP TEMPORARY FUNCTION SeSsIoN.my_func
The Thrift Server was failing to resolve qualified function names like
system.builtin.abs because ResolveCatalogs.resolveFunctionIdentifier
was not checking for builtin/temp namespace qualifications.

Issue:
- SELECT system.builtin.abs(-5) failed with REQUIRES_SINGLE_PART_NAMESPACE
- The error occurred in Thrift Server path (DDL commands: DROP FUNCTION,
  REFRESH FUNCTION) which uses ResolveCatalogs rule
- For multi-part names, it blindly called CatalogAndIdentifier which
  tried to resolve 'system' as a catalog, failed, and fell back to
  treating it as (currentCatalog, Identifier["system", "builtin"], "abs")
- This created an Identifier with 2-part namespace which violated the
  single-part requirement

Fix:
- Updated resolveFunctionIdentifier to check for qualified builtin/temp
  names before falling back to CatalogAndIdentifier
- Moved helper methods (maybeBuiltinFunctionName, maybeTempFunctionName,
  isQualifiedWithNamespace) to FunctionResolution companion object
- Both FunctionResolution class and ResolveCatalogs now share the same
  qualification logic (DRY principle)

Now correctly handles:
- system.builtin.abs, builtin.abs (builtin functions)
- system.session.func, session.func (temp functions)
- Unqualified function names (existing behavior)
- External catalog functions (existing behavior)

Testing:
- Regular SQL tests: PASSED
- Thrift Server tests: to be verified
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants