Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 3 Jun 2016 09:34:59 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12916743.1448729378000.23953.1464946499248@Atlassian.JIRA>
In-Reply-To: <JIRA.12916743.1448729378000@Atlassian.JIRA>
References: <JIRA.12916743.1448729378000@Atlassian.JIRA> <JIRA.12916743.1448729378414@arcas>
Subject: [jira] [Commented] (CASSANDRA-10783) Allow literal value as
 parameter of UDF & UDA
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 03 Jun 2016 09:35:01 -0000


    [ 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)