[
https://issues.apache.org/jira/browse/CASSANDRA-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15313900#comment-15313900
]
Sylvain Lebresne commented on CASSANDRA-10783:
----------------------------------------------
bq. we also have the text we can use it to narrow down the type to {{bigint}}
or {{int32}}
Yes, we can. I'm just not sure it's better than having a simple and consistent
behavior. Typically, if we go there, does that mean we try to use the smallest
type a literal work for, in which case we should use {{tinyint}}) for {{1}},
and we should check string literals to see if they fit {{ascii}} and uuid
literals to see if they are {{timeuuid}}. Certainly possible but do we want to
get there. The alternative being to have somewhat random rules for each type of
literals, but that's well random.
In truth, I don't really care some much about the default being {{varint}} in
{{SELECT 1 FROM ...}}, I think it doesn't really matter in that example because
if you wrote that, you probably don't intend to retrieve that column in the
resultset and the exact type probably doesn't matter. It's more than I don't
know if I want to introduce the notion of "default" types for literals in that
very patch, especially since I don't think it's that useful.
Typically, I suspect that we might want to introduce some kind of type
"preferences" for function resolution so that when we have {{add(2, 3)}} and
have multiple overload for {{add}}, we just default to one of the overload
(probably the most precise type, though worth discussing) and I feel that it's
the same kind of conversation (but somewhat more important than the question in
this ticket). Long story short, I've remove the default type thing mostly
because I think there is more to it than just this ticket and I'd rather
discuss it separately. But I agree there is more than one option as far as
picking the exact default type goes.
> Allow literal value as parameter of UDF & UDA
> ---------------------------------------------
>
> Key: CASSANDRA-10783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10783
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: DOAN DuyHai
> Assignee: Robert Stupp
> Priority: Minor
> Labels: CQL3, UDF, client-impacting, doc-impacting
> Fix For: 3.x
>
>
> I have defined the following UDF
> {code:sql}
> CREATE OR REPLACE FUNCTION maxOf(current int, testValue int) RETURNS NULL ON
> NULL INPUT
> RETURNS int
> LANGUAGE java
> AS 'return Math.max(current,testValue);'
> CREATE TABLE maxValue(id int primary key, val int);
> INSERT INTO maxValue(id, val) VALUES(1, 100);
> SELECT maxOf(val, 101) FROM maxValue WHERE id=1;
> {code}
> I got the following error message:
> {code}
> SyntaxException: <ErrorMessage code=2000 [Syntax error in CQL query]
> message="line 1:19 no viable alternative at input '101' (SELECT maxOf(val1,
> [101]...)">
> {code}
> It would be nice to allow literal value as parameter of UDF and UDA too.
> I was thinking about an use-case for an UDA groupBy() function where the end
> user can *inject* at runtime a literal value to select which aggregation he
> want to display, something similar to GROUP BY ... HAVING <filter clause>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
