[
https://issues.apache.org/jira/browse/CASSANDRA-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106640#comment-14106640
]
Sylvain Lebresne commented on CASSANDRA-7809:
---------------------------------------------
bq. Maybe put a placeholder in the map of declared functions?
Good idea as that also allows to provide a more meaningful error message when
the badly-loaded function is executed. I've pushed an additional commit to the
branch.
bq. Just return argRes if it's not EXACT_MATCH
That's not exactly what we want because even if we get a {{WEAKLY_ASSIGNABLE}},
we still need to finish the loop to check if some argument might be not
assignable at all. But arguably the switch was not super elegant so I changed
it and added a comment.
bq. Why does Maps/Sets/Lists.testAssignment() return WEAKLY_ASSIGNABLE for
exact matches?
That was part-laziness and part because it's not really all that useful in
practice (it'll make a difference for something like '\{(int)?, (int)?,
(int)?}' but that's about it, and why would you ever write that when you can
write '(set<int>){?, ?, ?}' or really just '(set<int>)?' ?). But anyway,
neither are extremely good reasons so I've fixed it.
> UDF cleanups (#7395 follow-up)
> ------------------------------
>
> Key: CASSANDRA-7809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7809
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Labels: cql
> Fix For: 3.0
>
>
> The current code for UDF is largely not reusing the pre-existing
> mechanics/code for native/hardcoded functions. I don't see a good reason for
> that but I do see downsides: it's more code to maintain and makes it much
> easier to have inconsitent behavior between hard-coded and user-defined
> function. More concretely, {{UDFRegistery/UDFFunctionOverloads}}
> fundamentally do the same thing than {{Functions}}, we should just merge
> both. I'm also not sure there is a need for both {{UFMetadata}} and
> {{UDFunction}} since {{UFMetadata}} really only store infos on a given
> function (contrarly to what the javadoc pretends). I suggest we consolidate
> all this to cleanup the code, but also as a way to fix 2 problems that the
> UDF code has but that the existing code for "native" functions don't:
> * if there is multiple overloads of a function, the UDF code picks the first
> version whose argument types are compatible with the concrete arguments
> provided. This is broken for bind markers: we don't know the type of markers
> and so the first function match may not at all be what the user want. The
> only sensible choice is to detect that type of ambiguity and reject the
> query, asking the user to explicitly type-cast their bind marker (which is
> what the code for hard-coded function does).
> * the UDF code builds a function signature using the CQL type names of the
> arguments and use that to distinguish multiple overrides in the schema. This
> means in particular that {{f(v text)}} and {{f(v varchar)}} are considered
> distinct, which is wrong since CQL considers {{varchar}} as a simple alias of
> {{text}}. And in fact, the function resolution does consider them aliases
> leading to seemingly broken behavior.
> There is a few other small problems that I'm proposing to fix while doing
> this cleanup:
> * Function creation only use the function name when checking if the function
> exists, which is not enough since we allow multiple over-loadings. You can
> bypass the check by using "OR REPLACE" but that's obviously broken.
> * {{IF NOT EXISTS}} for function creation is broken.
> * The code allows to replace a function (with {{OR REPLACE}}) by a new
> function with an incompatible return type. Imo that's dodgy and we should
> refuse it (users can still drop and re-create the method if they really want).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
