You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Andrés de la Peña <ad...@apache.org> on 2022/11/10 12:20:46 UTC
Naming conventions for CQL native functions
It seems we don't have a clear convention on how to name CQL native
functions.
Most native functions are named all lower case, without underscore nor
hyphen to separate words. That's the case, for example, of "intasblob" or
"blobasint".
We also have some functions using camel case, as in "castAsInt" or
"castAsTimestamp". Note that the came cased names require quoting due to
CQL's case insensitivity.
Differently to CQL native functions, system keyspaces, tables and columns
consistently use snake case. For example, we have "system_schema",
"dropped_columns", "default_time_to_live".
I think it would be good to adopt a convention on how to name CQL native
functions, at least the new ones. IMO camel case would make sense because
it plays well with CQL's case insensitivity, it makes long names easier to
read and it's consistent with the names used for most other things.
For example, in CASSANDRA-17811 I'm working on a set of functions to do
within-collection operations, which would be named "map_keys",
"map_values", "collection_min", "collection_max", "collection_sum",
"collection_count", etc. Also, CEP-20 will add a set of functions that
would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
"mask_outer", "mask_hash", etc.
As for the already existing functions, we could either let them be or add
snake case aliases for them, so for example we'd have both "castAsInt" and
"cast_as_int", at least for a time.
What do you think?
Re: Naming conventions for CQL native functions
Posted by Berenguer Blasi <be...@gmail.com>.
+1 to consolidating on one option and aliasing where needed. Avoiding
camel-case to spare the user the quoting seems also like a good idea to me.
On 10/11/22 13:20, Andrés de la Peña wrote:
> It seems we don't have a clear convention on how to name CQL native
> functions.
>
> Most native functions are named all lower case, without underscore nor
> hyphen to separate words. That's the case, for example, of "intasblob"
> or "blobasint".
>
> We also have some functions using camel case, as in "castAsInt" or
> "castAsTimestamp". Note that the came cased names require quoting due
> to CQL's case insensitivity.
>
> Differently to CQL native functions, system keyspaces, tables and
> columns consistently use snake case. For example, we have
> "system_schema", "dropped_columns", "default_time_to_live".
>
> I think it would be good to adopt a convention on how to name CQL
> native functions, at least the new ones. IMO camel case would make
> sense because it plays well with CQL's case insensitivity, it makes
> long names easier to read and it's consistent with the names used for
> most other things.
>
> For example, in CASSANDRA-17811 I'm working on a set of functions to
> do within-collection operations, which would be named "map_keys",
> "map_values", "collection_min", "collection_max", "collection_sum",
> "collection_count", etc. Also, CEP-20 will add a set of functions that
> would be named "mask_null", "mask_default", "mask_replace",
> "mask_inner", "mask_outer", "mask_hash", etc.
>
> As for the already existing functions, we could either let them be or
> add snake case aliases for them, so for example we'd have both
> "castAsInt" and "cast_as_int", at least for a time.
>
> What do you think?
Re: Naming conventions for CQL native functions
Posted by Ekaterina Dimitrova <e....@gmail.com>.
+1 from me too on camel case and the aliases for compatibility
On Thu, 10 Nov 2022 at 7:47, Miklosovic, Stefan <
Stefan.Miklosovic@netapp.com> wrote:
> Adding snake case aliases for existing functions which are in camel case
> for compatibility and stick to snake case from now on seems to be like a
> good idea.
>
> ________________________________________
> From: Andrés de la Peña <ad...@apache.org>
> Sent: Thursday, November 10, 2022 13:20
> To: dev@cassandra.apache.org
> Subject: Naming conventions for CQL native functions
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> It seems we don't have a clear convention on how to name CQL native
> functions.
>
> Most native functions are named all lower case, without underscore nor
> hyphen to separate words. That's the case, for example, of "intasblob" or
> "blobasint".
>
> We also have some functions using camel case, as in "castAsInt" or
> "castAsTimestamp". Note that the came cased names require quoting due to
> CQL's case insensitivity.
>
> Differently to CQL native functions, system keyspaces, tables and columns
> consistently use snake case. For example, we have "system_schema",
> "dropped_columns", "default_time_to_live".
>
> I think it would be good to adopt a convention on how to name CQL native
> functions, at least the new ones. IMO camel case would make sense because
> it plays well with CQL's case insensitivity, it makes long names easier to
> read and it's consistent with the names used for most other things.
>
> For example, in CASSANDRA-17811 I'm working on a set of functions to do
> within-collection operations, which would be named "map_keys",
> "map_values", "collection_min", "collection_max", "collection_sum",
> "collection_count", etc. Also, CEP-20 will add a set of functions that
> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
> "mask_outer", "mask_hash", etc.
>
> As for the already existing functions, we could either let them be or add
> snake case aliases for them, so for example we'd have both "castAsInt" and
> "cast_as_int", at least for a time.
>
> What do you think?
>
Re: Naming conventions for CQL native functions
Posted by "Miklosovic, Stefan" <St...@netapp.com>.
Adding snake case aliases for existing functions which are in camel case for compatibility and stick to snake case from now on seems to be like a good idea.
________________________________________
From: Andrés de la Peña <ad...@apache.org>
Sent: Thursday, November 10, 2022 13:20
To: dev@cassandra.apache.org
Subject: Naming conventions for CQL native functions
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
It seems we don't have a clear convention on how to name CQL native functions.
Most native functions are named all lower case, without underscore nor hyphen to separate words. That's the case, for example, of "intasblob" or "blobasint".
We also have some functions using camel case, as in "castAsInt" or "castAsTimestamp". Note that the came cased names require quoting due to CQL's case insensitivity.
Differently to CQL native functions, system keyspaces, tables and columns consistently use snake case. For example, we have "system_schema", "dropped_columns", "default_time_to_live".
I think it would be good to adopt a convention on how to name CQL native functions, at least the new ones. IMO camel case would make sense because it plays well with CQL's case insensitivity, it makes long names easier to read and it's consistent with the names used for most other things.
For example, in CASSANDRA-17811 I'm working on a set of functions to do within-collection operations, which would be named "map_keys", "map_values", "collection_min", "collection_max", "collection_sum", "collection_count", etc. Also, CEP-20 will add a set of functions that would be named "mask_null", "mask_default", "mask_replace", "mask_inner", "mask_outer", "mask_hash", etc.
As for the already existing functions, we could either let them be or add snake case aliases for them, so for example we'd have both "castAsInt" and "cast_as_int", at least for a time.
What do you think?
Re: Naming conventions for CQL native functions
Posted by Andrés de la Peña <ad...@apache.org>.
Thanks for the feedback. Adopting snake case and using aliases seems pretty
uncontroversial so far. I have created CASSANDRA-18037
<https://issues.apache.org/jira/browse/CASSANDRA-18037> for doing it.
On Thu, 10 Nov 2022 at 19:06, Jeremy Hanna <je...@gmail.com>
wrote:
> +1 (nb) mixed case is a miserable experience and snake case makes it
> readable.
>
> > On Nov 10, 2022, at 10:57 AM, Francisco Guerrero <fr...@apache.org>
> wrote:
> >
> > +1 (nb) as well
> >
> >> On 2022/11/10 17:16:21 Caleb Rackliffe wrote:
> >> +100 on snake case for built-in functions given I think MySQL and
> Postgres
> >> use that convention as well.
> >>
> >> ex. https://www.postgresql.org/docs/9.2/functions-string.html
> >>
> >>> On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams <dr...@gmail.com>
> wrote:
> >>>
> >>> I too meant snake case and need coffee.
> >>>
> >>>> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams <dr...@gmail.com>
> wrote:
> >>>
> >>>> +1 on camel case and aliases for compatibility.
> >>>>
> >>>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <adelapena@apache.org
> >
> >>>> wrote:
> >>>>
> >>>>> It seems we don't have a clear convention on how to name CQL native
> >>>>> functions.
> >>>>>
> >>>>> Most native functions are named all lower case, without underscore
> nor
> >>>>> hyphen to separate words. That's the case, for example, of
> "intasblob" or
> >>>>> "blobasint".
> >>>>>
> >>>>> We also have some functions using camel case, as in "castAsInt" or
> >>>>> "castAsTimestamp". Note that the came cased names require quoting
> due to
> >>>>> CQL's case insensitivity.
> >>>>>
> >>>>> Differently to CQL native functions, system keyspaces, tables and
> >>>>> columns consistently use snake case. For example, we have
> "system_schema",
> >>>>> "dropped_columns", "default_time_to_live".
> >>>>>
> >>>>> I think it would be good to adopt a convention on how to name CQL
> native
> >>>>> functions, at least the new ones. IMO camel case would make sense
> because
> >>>>> it plays well with CQL's case insensitivity, it makes long names
> easier to
> >>>>> read and it's consistent with the names used for most other things.
> >>>>>
> >>>>> For example, in CASSANDRA-17811 I'm working on a set of functions to
> do
> >>>>> within-collection operations, which would be named "map_keys",
> >>>>> "map_values", "collection_min", "collection_max", "collection_sum",
> >>>>> "collection_count", etc. Also, CEP-20 will add a set of functions
> that
> >>>>> would be named "mask_null", "mask_default", "mask_replace",
> "mask_inner",
> >>>>> "mask_outer", "mask_hash", etc.
> >>>>>
> >>>>> As for the already existing functions, we could either let them be or
> >>>>> add snake case aliases for them, so for example we'd have both
> "castAsInt"
> >>>>> and "cast_as_int", at least for a time.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>
> >>
>
Re: Naming conventions for CQL native functions
Posted by Jeremy Hanna <je...@gmail.com>.
+1 (nb) mixed case is a miserable experience and snake case makes it readable.
> On Nov 10, 2022, at 10:57 AM, Francisco Guerrero <fr...@apache.org> wrote:
>
> +1 (nb) as well
>
>> On 2022/11/10 17:16:21 Caleb Rackliffe wrote:
>> +100 on snake case for built-in functions given I think MySQL and Postgres
>> use that convention as well.
>>
>> ex. https://www.postgresql.org/docs/9.2/functions-string.html
>>
>>> On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams <dr...@gmail.com> wrote:
>>>
>>> I too meant snake case and need coffee.
>>>
>>>> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams <dr...@gmail.com> wrote:
>>>
>>>> +1 on camel case and aliases for compatibility.
>>>>
>>>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
>>>> wrote:
>>>>
>>>>> It seems we don't have a clear convention on how to name CQL native
>>>>> functions.
>>>>>
>>>>> Most native functions are named all lower case, without underscore nor
>>>>> hyphen to separate words. That's the case, for example, of "intasblob" or
>>>>> "blobasint".
>>>>>
>>>>> We also have some functions using camel case, as in "castAsInt" or
>>>>> "castAsTimestamp". Note that the came cased names require quoting due to
>>>>> CQL's case insensitivity.
>>>>>
>>>>> Differently to CQL native functions, system keyspaces, tables and
>>>>> columns consistently use snake case. For example, we have "system_schema",
>>>>> "dropped_columns", "default_time_to_live".
>>>>>
>>>>> I think it would be good to adopt a convention on how to name CQL native
>>>>> functions, at least the new ones. IMO camel case would make sense because
>>>>> it plays well with CQL's case insensitivity, it makes long names easier to
>>>>> read and it's consistent with the names used for most other things.
>>>>>
>>>>> For example, in CASSANDRA-17811 I'm working on a set of functions to do
>>>>> within-collection operations, which would be named "map_keys",
>>>>> "map_values", "collection_min", "collection_max", "collection_sum",
>>>>> "collection_count", etc. Also, CEP-20 will add a set of functions that
>>>>> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
>>>>> "mask_outer", "mask_hash", etc.
>>>>>
>>>>> As for the already existing functions, we could either let them be or
>>>>> add snake case aliases for them, so for example we'd have both "castAsInt"
>>>>> and "cast_as_int", at least for a time.
>>>>>
>>>>> What do you think?
>>>>>
>>>>
>>
Re: Naming conventions for CQL native functions
Posted by Francisco Guerrero <fr...@apache.org>.
+1 (nb) as well
On 2022/11/10 17:16:21 Caleb Rackliffe wrote:
> +100 on snake case for built-in functions given I think MySQL and Postgres
> use that convention as well.
>
> ex. https://www.postgresql.org/docs/9.2/functions-string.html
>
> On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams <dr...@gmail.com> wrote:
>
> > I too meant snake case and need coffee.
> >
> > On Thu, Nov 10, 2022, 7:26 AM Brandon Williams <dr...@gmail.com> wrote:
> >
> >> +1 on camel case and aliases for compatibility.
> >>
> >> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
> >> wrote:
> >>
> >>> It seems we don't have a clear convention on how to name CQL native
> >>> functions.
> >>>
> >>> Most native functions are named all lower case, without underscore nor
> >>> hyphen to separate words. That's the case, for example, of "intasblob" or
> >>> "blobasint".
> >>>
> >>> We also have some functions using camel case, as in "castAsInt" or
> >>> "castAsTimestamp". Note that the came cased names require quoting due to
> >>> CQL's case insensitivity.
> >>>
> >>> Differently to CQL native functions, system keyspaces, tables and
> >>> columns consistently use snake case. For example, we have "system_schema",
> >>> "dropped_columns", "default_time_to_live".
> >>>
> >>> I think it would be good to adopt a convention on how to name CQL native
> >>> functions, at least the new ones. IMO camel case would make sense because
> >>> it plays well with CQL's case insensitivity, it makes long names easier to
> >>> read and it's consistent with the names used for most other things.
> >>>
> >>> For example, in CASSANDRA-17811 I'm working on a set of functions to do
> >>> within-collection operations, which would be named "map_keys",
> >>> "map_values", "collection_min", "collection_max", "collection_sum",
> >>> "collection_count", etc. Also, CEP-20 will add a set of functions that
> >>> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
> >>> "mask_outer", "mask_hash", etc.
> >>>
> >>> As for the already existing functions, we could either let them be or
> >>> add snake case aliases for them, so for example we'd have both "castAsInt"
> >>> and "cast_as_int", at least for a time.
> >>>
> >>> What do you think?
> >>>
> >>
>
Re: Naming conventions for CQL native functions
Posted by Caleb Rackliffe <ca...@gmail.com>.
+100 on snake case for built-in functions given I think MySQL and Postgres
use that convention as well.
ex. https://www.postgresql.org/docs/9.2/functions-string.html
On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams <dr...@gmail.com> wrote:
> I too meant snake case and need coffee.
>
> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams <dr...@gmail.com> wrote:
>
>> +1 on camel case and aliases for compatibility.
>>
>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
>> wrote:
>>
>>> It seems we don't have a clear convention on how to name CQL native
>>> functions.
>>>
>>> Most native functions are named all lower case, without underscore nor
>>> hyphen to separate words. That's the case, for example, of "intasblob" or
>>> "blobasint".
>>>
>>> We also have some functions using camel case, as in "castAsInt" or
>>> "castAsTimestamp". Note that the came cased names require quoting due to
>>> CQL's case insensitivity.
>>>
>>> Differently to CQL native functions, system keyspaces, tables and
>>> columns consistently use snake case. For example, we have "system_schema",
>>> "dropped_columns", "default_time_to_live".
>>>
>>> I think it would be good to adopt a convention on how to name CQL native
>>> functions, at least the new ones. IMO camel case would make sense because
>>> it plays well with CQL's case insensitivity, it makes long names easier to
>>> read and it's consistent with the names used for most other things.
>>>
>>> For example, in CASSANDRA-17811 I'm working on a set of functions to do
>>> within-collection operations, which would be named "map_keys",
>>> "map_values", "collection_min", "collection_max", "collection_sum",
>>> "collection_count", etc. Also, CEP-20 will add a set of functions that
>>> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
>>> "mask_outer", "mask_hash", etc.
>>>
>>> As for the already existing functions, we could either let them be or
>>> add snake case aliases for them, so for example we'd have both "castAsInt"
>>> and "cast_as_int", at least for a time.
>>>
>>> What do you think?
>>>
>>
Re: Naming conventions for CQL native functions
Posted by Brandon Williams <dr...@gmail.com>.
I too meant snake case and need coffee.
On Thu, Nov 10, 2022, 7:26 AM Brandon Williams <dr...@gmail.com> wrote:
> +1 on camel case and aliases for compatibility.
>
> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
> wrote:
>
>> It seems we don't have a clear convention on how to name CQL native
>> functions.
>>
>> Most native functions are named all lower case, without underscore nor
>> hyphen to separate words. That's the case, for example, of "intasblob" or
>> "blobasint".
>>
>> We also have some functions using camel case, as in "castAsInt" or
>> "castAsTimestamp". Note that the came cased names require quoting due to
>> CQL's case insensitivity.
>>
>> Differently to CQL native functions, system keyspaces, tables and columns
>> consistently use snake case. For example, we have "system_schema",
>> "dropped_columns", "default_time_to_live".
>>
>> I think it would be good to adopt a convention on how to name CQL native
>> functions, at least the new ones. IMO camel case would make sense because
>> it plays well with CQL's case insensitivity, it makes long names easier to
>> read and it's consistent with the names used for most other things.
>>
>> For example, in CASSANDRA-17811 I'm working on a set of functions to do
>> within-collection operations, which would be named "map_keys",
>> "map_values", "collection_min", "collection_max", "collection_sum",
>> "collection_count", etc. Also, CEP-20 will add a set of functions that
>> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
>> "mask_outer", "mask_hash", etc.
>>
>> As for the already existing functions, we could either let them be or add
>> snake case aliases for them, so for example we'd have both "castAsInt" and
>> "cast_as_int", at least for a time.
>>
>> What do you think?
>>
>
Re: Naming conventions for CQL native functions
Posted by Ekaterina Dimitrova <e....@gmail.com>.
Oh, I meant snake, yes. I need a coffee 😀
На четвъртък, 10 ноември 2022 г. Andrés de la Peña <ad...@apache.org>
написа:
> IMO camel case would make sense because it plays well with CQL's case
>> insensitivity, it makes long names easier to read and it's consistent with
>> the names used for most other things.
>
>
> I meant that we should use snake case, as in "collection_max" and the
> other example I give, but I wrongly wrote camel case instead. I'm sorry for
> the confusion. I understand that Ekaterina and Brandon meant the same,
> adopting snake_case as the convention and use camelCase aliases for
> compatibility.
>
> On Thu, 10 Nov 2022 at 13:26, Brandon Williams <dr...@gmail.com> wrote:
>
>> +1 on camel case and aliases for compatibility.
>>
>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
>> wrote:
>>
>>> It seems we don't have a clear convention on how to name CQL native
>>> functions.
>>>
>>> Most native functions are named all lower case, without underscore nor
>>> hyphen to separate words. That's the case, for example, of "intasblob" or
>>> "blobasint".
>>>
>>> We also have some functions using camel case, as in "castAsInt" or
>>> "castAsTimestamp". Note that the came cased names require quoting due to
>>> CQL's case insensitivity.
>>>
>>> Differently to CQL native functions, system keyspaces, tables and
>>> columns consistently use snake case. For example, we have "system_schema",
>>> "dropped_columns", "default_time_to_live".
>>>
>>> I think it would be good to adopt a convention on how to name CQL native
>>> functions, at least the new ones. IMO camel case would make sense because
>>> it plays well with CQL's case insensitivity, it makes long names easier to
>>> read and it's consistent with the names used for most other things.
>>>
>>> For example, in CASSANDRA-17811 I'm working on a set of functions to do
>>> within-collection operations, which would be named "map_keys",
>>> "map_values", "collection_min", "collection_max", "collection_sum",
>>> "collection_count", etc. Also, CEP-20 will add a set of functions that
>>> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
>>> "mask_outer", "mask_hash", etc.
>>>
>>> As for the already existing functions, we could either let them be or
>>> add snake case aliases for them, so for example we'd have both "castAsInt"
>>> and "cast_as_int", at least for a time.
>>>
>>> What do you think?
>>>
>>
Re: Naming conventions for CQL native functions
Posted by Andrés de la Peña <ad...@apache.org>.
>
> IMO camel case would make sense because it plays well with CQL's case
> insensitivity, it makes long names easier to read and it's consistent with
> the names used for most other things.
I meant that we should use snake case, as in "collection_max" and the other
example I give, but I wrongly wrote camel case instead. I'm sorry for the
confusion. I understand that Ekaterina and Brandon meant the same, adopting
snake_case as the convention and use camelCase aliases for compatibility.
On Thu, 10 Nov 2022 at 13:26, Brandon Williams <dr...@gmail.com> wrote:
> +1 on camel case and aliases for compatibility.
>
> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
> wrote:
>
>> It seems we don't have a clear convention on how to name CQL native
>> functions.
>>
>> Most native functions are named all lower case, without underscore nor
>> hyphen to separate words. That's the case, for example, of "intasblob" or
>> "blobasint".
>>
>> We also have some functions using camel case, as in "castAsInt" or
>> "castAsTimestamp". Note that the came cased names require quoting due to
>> CQL's case insensitivity.
>>
>> Differently to CQL native functions, system keyspaces, tables and columns
>> consistently use snake case. For example, we have "system_schema",
>> "dropped_columns", "default_time_to_live".
>>
>> I think it would be good to adopt a convention on how to name CQL native
>> functions, at least the new ones. IMO camel case would make sense because
>> it plays well with CQL's case insensitivity, it makes long names easier to
>> read and it's consistent with the names used for most other things.
>>
>> For example, in CASSANDRA-17811 I'm working on a set of functions to do
>> within-collection operations, which would be named "map_keys",
>> "map_values", "collection_min", "collection_max", "collection_sum",
>> "collection_count", etc. Also, CEP-20 will add a set of functions that
>> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
>> "mask_outer", "mask_hash", etc.
>>
>> As for the already existing functions, we could either let them be or add
>> snake case aliases for them, so for example we'd have both "castAsInt" and
>> "cast_as_int", at least for a time.
>>
>> What do you think?
>>
>
Re: Naming conventions for CQL native functions
Posted by Brandon Williams <dr...@gmail.com>.
+1 on camel case and aliases for compatibility.
On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <ad...@apache.org>
wrote:
> It seems we don't have a clear convention on how to name CQL native
> functions.
>
> Most native functions are named all lower case, without underscore nor
> hyphen to separate words. That's the case, for example, of "intasblob" or
> "blobasint".
>
> We also have some functions using camel case, as in "castAsInt" or
> "castAsTimestamp". Note that the came cased names require quoting due to
> CQL's case insensitivity.
>
> Differently to CQL native functions, system keyspaces, tables and columns
> consistently use snake case. For example, we have "system_schema",
> "dropped_columns", "default_time_to_live".
>
> I think it would be good to adopt a convention on how to name CQL native
> functions, at least the new ones. IMO camel case would make sense because
> it plays well with CQL's case insensitivity, it makes long names easier to
> read and it's consistent with the names used for most other things.
>
> For example, in CASSANDRA-17811 I'm working on a set of functions to do
> within-collection operations, which would be named "map_keys",
> "map_values", "collection_min", "collection_max", "collection_sum",
> "collection_count", etc. Also, CEP-20 will add a set of functions that
> would be named "mask_null", "mask_default", "mask_replace", "mask_inner",
> "mask_outer", "mask_hash", etc.
>
> As for the already existing functions, we could either let them be or add
> snake case aliases for them, so for example we'd have both "castAsInt" and
> "cast_as_int", at least for a time.
>
> What do you think?
>