Register the split-span and inherited accessor names once, from the catalog - #354
Merged
estebanzimanyi merged 1 commit intoAug 29, 2026
Merged
Conversation
…atalog The generator emits these names from the catalog for every type it declares them over, so the hand registrations beside them add nothing: 55 of them repeat a generated (name, argument types) pair exactly, and DuckDB keeps one overload per signature, so the hand copy only decides which spelling duckdb_functions() reports. splitNspans and splitEachNspans go with them. MobilityDB declares splitNSpans and splitEachNSpans, the catalog carries that spelling in sqlfn, and the generator emits it; DuckDB resolves a function name without regard to case, so splitnspans, splitNSpans and SPLITNSPANS all reach the same overload and the lowercase registrations reach nothing the canonical one does not. The registered surface is identical either way: duckdb_functions() reports the same 11625 rows, and startInstant, endInstant, instantN, interp, tempSubtype, intset, floatset, intspan, splitNSpans, lower, initcap and nearestApproachDistance answer the same values.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The generator emits these names from the catalog for every type it declares
them over, so the hand registrations beside them add nothing: 55 of them
repeat a generated (name, argument types) pair exactly, and DuckDB keeps one
overload per signature, so the hand copy only decides which spelling
duckdb_functions() reports.
splitNspans and splitEachNspans go with them. MobilityDB declares
splitNSpans and splitEachNSpans, the catalog carries that spelling in sqlfn,
and the generator emits it; DuckDB resolves a function name without regard to
case, so splitnspans, splitNSpans and SPLITNSPANS all reach the same overload
and the lowercase registrations reach nothing the canonical one does not.
The registered surface is identical either way: duckdb_functions() reports the
same 11625 rows, and startInstant, endInstant, instantN, interp, tempSubtype,
intset, floatset, intspan, splitNSpans, lower, initcap and
nearestApproachDistance answer the same values.