+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? > >>> > >> >
