[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057588#comment-14057588
]
Jonathan Ellis commented on CASSANDRA-7395:
-------------------------------------------
bq. Regarding the "deterministic" keyword. It's possible to define
non-deterministic functions as "deterministic" in Oracle for example and use it
in a functional index (which does not work, of course). The keyword's just
there to prevent accidental use of non-deterministic functions.
Postgresql uses immutable|stable|volatile keywoards for similar reasons, but I
don't think making our query planner powerful enough to care about the
distinction is in-scope here:
{quote}
IMMUTABLE indicates that the function cannot modify the database and always
returns the same result when given the same argument values; that is, it does
not do database lookups or otherwise use information not directly present in
its argument list. If this option is given, any call of the function with
all-constant arguments can be immediately replaced with the function value.
STABLE indicates that the function cannot modify the database, and that within
a single table scan it will consistently return the same result for the same
argument values, but that its result could change across SQL statements. This
is the appropriate selection for functions whose results depend on database
lookups, parameter variables (such as the current time zone), etc. (It is
inappropriate for AFTER triggers that wish to query rows modified by the
current command.) Also note that the current_timestamp family of functions
qualify as stable, since their values do not change within a transaction.
VOLATILE indicates that the function value can change even within a single
table scan, so no optimizations can be made. Relatively few database functions
are volatile in this sense; some examples are random(), currval(), timeofday().
But note that any function that has side-effects must be classified volatile,
even if its result is quite predictable, to prevent calls from being optimized
away; an example is setval().
{quote}
http://www.postgresql.org/docs/9.1/static/sql-createfunction.html
> Support for pure user-defined functions (UDF)
> ---------------------------------------------
>
> Key: CASSANDRA-7395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Labels: cql
> Fix For: 3.0
>
> Attachments: 7395-v2.diff, 7395.diff
>
>
> We have some tickets for various aspects of UDF (CASSANDRA-4914,
> CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of
> ocean-boiling.
> Let's start with something simple: allowing pure user-defined functions in
> the SELECT clause of a CQL query. That's it.
> By "pure" I mean, must depend only on the input parameters. No side effects.
> No exposure to C* internals. Column values in, result out.
> http://en.wikipedia.org/wiki/Pure_function
--
This message was sent by Atlassian JIRA
(v6.2#6252)
