> I do not think we should have functions that aggregate across rows and
> functions that operate within a row use the same name.
I’m sympathetic to that view for sure. I wouldn’t be too disappointed by that
outcome, and SQL engines seem to take a similar approach, however they mostly
rely on
IMO it's wrong to change an aggregate's meaning from "aggregate across
GROUPs or entire SELECT" to "aggregate within column". Aggregation is
long established in SQL and it will just confuse experienced database
users.
PostgresQL maintains the meaning of max:
CREATE TABLE tab (
x int[]
);
INS
I meant unnest, not unwrap.
> On 8 Dec 2022, at 10:34, Benedict wrote:
>
>
>
>> I do not think we should have functions that aggregate across rows and
>> functions that operate within a row use the same name.
>
> I’m sympathetic to that view for sure. I wouldn’t be too disappointed by that
I think the semantics of the situation is important here.
Let’s take MAX as our example aggregate function..
We all expect that in a DB context MAX(column) will return the value of the
column with the maximum value. That is the expected semantics of MAX.
The question here is that there are d
"ARRAY_MAX" and "ARRAY_MIN" functions to get the max/min element in a list
are not an uncommon practice. You can find them in SparkSQL, Amazon
Timestream, Teradata, etc. Since we have what we call collections instead
or arrays, it makes sense to call the analogous functions "COLLECTION_MAX",
"COLLE
1) Do they offer ARRAY_SUM or ARRAY_AVG?
2) Do they define ARRAY_COUNT or ARRAY_LENGTH?
3) A map is a collection in C* parlance, but I gather from below you expect
these methods not to operate on them?
Does ARRAY_MAX operate on single values? If we are to base our decisions on
norms elsewhere, w
Hi,
I wanted to discuss the addition of the following dependencies for CEP-7.
The dependencies are:
org.apache.lucene.lucene-core 7.5.0
org.apache.lucene.lucene-analyzers-common 7.5.0
com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test
dependency
Lucene is an apache project
>
> 1) Do they offer ARRAY_SUM or ARRAY_AVG?
Yes, a quick search on Google shows some examples:
https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/68fdFR3LWhx7KtHc9Iv5Qg
https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/gxz1nB7GclxNO5mBd~rn8g
https://docs.upsolver.com/sqlake/functions-and-operato
>> 1) Do they offer ARRAY_SUM or ARRAY_AVG?
> Yes, a quick search on Google shows some examples:
> https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/68fdFR3LWhx7KtHc9Iv5Qg
> https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/gxz1nB7GclxNO5mBd~rn8g
> https://docs.upsolver.com/sqlake/functions-and-
>> 1) Do they offer ARRAY_SUM or ARRAY_AVG?
> Yes, a quick search on Google shows some examples:
> https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/68fdFR3LWhx7KtHc9Iv5Qg
> https://docs.teradata.com/r/kmuOwjp1zEYg98JsB8fu_A/gxz1nB7GclxNO5mBd~rn8g
> https://docs.upsolver.com/sqlake/functions-and-
It feels like this is a recurring kind of discussion, and I wonder if there’s
any value in deciding on a general approach to guide these discussions in
future? Are we aiming to look like SQL as we evolve, and if so which products
do we want to be informed by?
I expect we’ll rehash it every API
>
> I expect we’ll rehash it every API thread otherwise.
Since you bring up the topic, I understand that opposing to every single
reviewed decision that has been taken on CASSANDRA-17811, CASSANDRA-8877,
CASSANDRA-17425 and CASSANDRA-18085 could make an argument in favour of the
policy demanding
I think this thread proves the point that a DISCUSS thread for API changes on dev@ will get more viewpoints than just having something in JIRA. I think this thread has been useful and should result in us having a better user facing API than without it.On Dec 8, 2022, at 1:57 PM, Andrés de la Peña
13 matches
Mail list logo
