Re: Naming conventions for CQL native functions

Thanks for the feedback. Adopting snake case and using aliases seems pretty uncontroversial so far. I have created CASSANDRA-18037 for doing it. On Thu, 10 Nov 2022 at 19:06, Jeremy Hanna wrote: > +1 (nb) mixed case is a miserable experienc

Re: Naming conventions for CQL native functions

+1 (nb) mixed case is a miserable experience and snake case makes it readable. > On Nov 10, 2022, at 10:57 AM, Francisco Guerrero 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

Re: Naming conventions for CQL native functions

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

Re: Naming conventions for CQL native functions

+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 wrote: > I too meant snake case and need coffee. > > On Thu, Nov 10, 2022, 7:26

Re: Naming conventions for CQL native functions

I too meant snake case and need coffee. On Thu, Nov 10, 2022, 7:26 AM Brandon Williams wrote: > +1 on camel case and aliases for compatibility. > > On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña > wrote: > >> It seems we don't have a clear convention on how to name CQL native >> functions. >>

Re: Naming conventions for CQL native functions

Oh, I meant snake, yes. I need a coffee 😀 На четвъртък, 10 ноември 2022 г. Andrés de la Peña написа: > 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. > >

Re: Naming conventions for CQL native functions

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

Re: Naming conventions for CQL native functions

+1 on camel case and aliases for compatibility. On Thu, Nov 10, 2022, 6:21 AM 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

Re: Naming conventions for CQL native functions

seems to be like a > good idea. > > > From: Andrés de la Peña > Sent: Thursday, November 10, 2022 13:20 > To: dev@cassandra.apache.org > Subject: Naming conventions for CQL native functions > > NetApp Security WARNING: This is a

Re: Naming conventions for CQL native functions

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 n

Re: Naming conventions for CQL native functions

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

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 "castAsI