New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: drop function/procedure with composite/table types doesn't work #114677
Comments
Hi @michae2, please add branch-* labels to identify which branch(es) this release-blocker affects. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
I don't think this needs to be a GA blocker, since the same problem affects 23.1:
|
It's a good point, but we are expecting this exact case (UDFs with composite type parameters) to be used much more in 23.2 than 23.1 by a specific customer, so I think we need to figure this out before we announce GA. |
The root cause seems to be that we hydrate the The solution is going to be reconciling this somehow, whether this means hydrating certain composite types as records, using tuple as the overload parameter type for composite types, or treating tuple and record as identical. |
I wonder if this relates to #102227 |
Note: this only reproduces when the function/proc name is overloaded, as in the example. |
Addendum to the preceding comment: It does repro when the function is not overloaded, but the workaround is to drop the function/proc without arguments. Here's an example:
|
I think this might have been the main problem - it looks like an oversight from when |
Previously, it was not possible to specify UDT parameters when dropping a routine. This is because of an oversight in `MatchAtIdentical`, which was likely copied from `MatchAt`. Specifically, `MatchAt` has special handling for tuple types that take advantage of the fact that `types.Equivalent` allows `types.AnyTuple` to match with any other tuple. `MatchAtIdentical, on the other hand, uses `types.Identical`, which does not make the same allowance. This meant that overload resolution would always fail for UDT parameters in code paths that use `MatchAtIdentical`, such as DROP FUNCTION. This patch removes the replacement logic for tuple types in `MatchAtIdentical`, so that `types.Identical` is always called with the original type. This allows statements like the following to succeed: ``` DROP PROCEDURE foo(x udt); ``` Fixes cockroachdb#114677 Release note (bug fix): Fixed a bug existing since v23.1 that prevented naming UDT parameters when dropping a user-defined function (or procedure).
Previously, it was not possible to specify UDT parameters when dropping a routine. This is because of an oversight in `MatchAtIdentical`, which was likely copied from `MatchAt`. Specifically, `MatchAt` has special handling for tuple types that take advantage of the fact that `types.Equivalent` allows `types.AnyTuple` to match with any other tuple. `MatchAtIdentical, on the other hand, uses `types.Identical`, which does not make the same allowance. This meant that overload resolution would always fail for UDT parameters in code paths that use `MatchAtIdentical`, such as DROP FUNCTION. This patch removes the replacement logic for tuple types in `MatchAtIdentical`, so that `types.Identical` is always called with the original type. This allows statements like the following to succeed: ``` DROP PROCEDURE foo(x udt); ``` Fixes cockroachdb#114677 Release note (bug fix): Fixed a bug existing since v23.1 that prevented naming UDT parameters when dropping a user-defined function (or procedure).
115848: sql: allow dropping routines with UDT-typed parameters r=DrewKimball a=DrewKimball Previously, it was not possible to specify UDT parameters when dropping a routine. This is because of an oversight in `MatchAtIdentical`, which was likely copied from `MatchAt`. Specifically, `MatchAt` has special handling for tuple types that take advantage of the fact that `types.Equivalent` allows `types.AnyTuple` to match with any other tuple. `MatchAtIdentical, on the other hand, uses `types.Identical`, which does not make the same allowance. This meant that overload resolution would always fail for UDT parameters in code paths that use `MatchAtIdentical`, such as DROP FUNCTION. This patch removes the replacement logic for tuple types in `MatchAtIdentical`, so that `types.Identical` is always called with the original type. This allows statements like the following to succeed: ``` DROP PROCEDURE foo(x udt); ``` Fixes #114677 Release note (bug fix): Fixed a bug existing since v23.1 that prevented naming UDT parameters when dropping a user-defined function (or procedure). Co-authored-by: Drew Kimball <drewk@cockroachlabs.com>
Previously, it was not possible to specify UDT parameters when dropping a routine. This is because of an oversight in `MatchAtIdentical`, which was likely copied from `MatchAt`. Specifically, `MatchAt` has special handling for tuple types that take advantage of the fact that `types.Equivalent` allows `types.AnyTuple` to match with any other tuple. `MatchAtIdentical, on the other hand, uses `types.Identical`, which does not make the same allowance. This meant that overload resolution would always fail for UDT parameters in code paths that use `MatchAtIdentical`, such as DROP FUNCTION. This patch removes the replacement logic for tuple types in `MatchAtIdentical`, so that `types.Identical` is always called with the original type. This allows statements like the following to succeed: ``` DROP PROCEDURE foo(x udt); ``` Fixes #114677 Release note (bug fix): Fixed a bug existing since v23.1 that prevented naming UDT parameters when dropping a user-defined function (or procedure).
Previously, it was not possible to specify UDT parameters when dropping a routine. This is because of an oversight in `MatchAtIdentical`, which was likely copied from `MatchAt`. Specifically, `MatchAt` has special handling for tuple types that take advantage of the fact that `types.Equivalent` allows `types.AnyTuple` to match with any other tuple. `MatchAtIdentical, on the other hand, uses `types.Identical`, which does not make the same allowance. This meant that overload resolution would always fail for UDT parameters in code paths that use `MatchAtIdentical`, such as DROP FUNCTION. This patch removes the replacement logic for tuple types in `MatchAtIdentical`, so that `types.Identical` is always called with the original type. This allows statements like the following to succeed: ``` DROP PROCEDURE foo(x udt); ``` Fixes #114677 Release note (bug fix): Fixed a bug existing since v23.1 that prevented naming UDT parameters when dropping a user-defined function (or procedure).
If a function or procedure is overloaded with different parameters, with one of those being a composite type, it becomes impossible to drop the func/proc with the composite parameter. Using the name of the type fails, as does surrounding the name in quotes, as well as changing it to uppercase. Surrounding the type name in quotes and changing it to uppercase seems to work, but the func/proc doesn't actually get dropped.
Jira issue: CRDB-33621
The text was updated successfully, but these errors were encountered: