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 <jeremy.hanna1...@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 <fran...@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 <dri...@gmail.com> > wrote: > >>> > >>> I too meant snake case and need coffee. > >>> > >>>> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams <dri...@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 <adelap...@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? > >>>>> > >>>> > >> >
