Join GitHub today
Add FunctionManager #11851
Add FunctionNamespace interface and StaticFunctionNamespace
- the commit message detail lines can be longer (72 characters), no need to wrap them at a shorter width
Add catalog and schema to Signature LGTM
I don't recall exactly why we wanted to add catalog and schema to the
Signature, but it was probably because it was simplifying the implementation.
Add FunctionManager as new function resolution class
A few changes:
"Move static methods from FunctionRegistry to FunctionUtils" looks good.
Use FunctionManager instead of FunctionRegistry in Metadata looks good.
@rongrong instead of saying
This PR contains the first 3 commits of #11161 with related build failures fixed. can you let me know what the change actually is, and maybe for this one, the motivation. I ask because this is a pretty small part of the changes from Cole, and removes the multiple namespaces part of his PR.
It looks like this change is basically to hide
FunctionRegistry using this abstraction chain:
FunctionNamespace -> `FunctionRegistry`. If so, I think we can make `FunctionNamespace` and `FunctionRegistry` package protected to prevent further leaking of their details.
It doesn't seem like
Signature.getCatalogSchemaName() is ever called, so I'm not sure why we are making this change now. (motivation and context would help here).
Other than the desire for more context this seems very straight forward.
@dain The author is no longer Cole because these are pretty much all reimplemented. The structure and content of all commits you are seeing now are dramatically changed compare to the original PR. There were a lot of git reset due to restructure of diffs which caused the name change. Not sure what's your motivation for put Cole's name behind it. I can change them to Cole, but these commits are probably 80%+ done by me at the moment and I should be responsible for them.
I agree about dropping the
Signature change for now, as it will be confusing to everyone since it is not used. I also suggest that
Add FunctionNamespace and FunctionManager and
Use FunctionManager instead of FunctionRegistry in Metadata be squashed together; they are not really independent, and I like to see the code along with the use if possible. Finally for the,
Move static methods from FunctionRegistry to FunctionUtils commit, I have suggestions for different organization (BTW, if you do that the commit will need a new title).
I read through both PRs, and this looks like all new code to me also, so the author tag is correct.
One minor comment. Looks good.
My point above about the
resolveLiteralFunction change is that we could encapsulate the magic literal concept, and gather all of that code that deal with it into the
LiteralEncoder. I think that change is independent of this PR, so I can deal with it after this goes in.
Looks good. However, it needs an explanation of the motivation in the commit message (especially the first one). Since these commits are a small part of a larger plan, they lack context and it looks like a somewhat unnecessary refactoring by themselves.