>
> Verbose version:
> LET (a) = SELECT val FROM table
> IF a > 1 THEN...
>
> Less verbose version:
> LET a = SELECT val FROM table
> IF a.val > 1 THEN...
My intention is that these are actually two different ways of expressing the
same thing, both supported and neither intended to be more
Let me just state my bias right up front. For any kind of QL I lean heavily
toward verbose and explicit based on their lifecycle. A CQL query will
probably need to be understood by the next person looking at it, and a few
seconds saved typing isn't worth the potential misunderstanding later. My
op
>
> I think SQL dialects require subqueries to be parenthesized (not sure). If
> that's the case I think we should keep the tradition.
>
This isn’t a sub-query though, since LET is not a query. If we permit at most
one SELECT, and do not permit mixing SELECT with constant assignments, I don’
On 14/08/2022 17.50, Benedict Elliott Smith wrote:
> SELECT and LET incompatible once comparisons become valid selectors
I don’t think this would be ambiguous, as = is required in the LET
syntax as we have to bind the result to a variable name.
But, I like the deconstructed tuple syntax im
> SELECT and LET incompatible once comparisons become valid selectors
I don’t think this would be ambiguous, as = is required in the LET syntax as we
have to bind the result to a variable name.
But, I like the deconstructed tuple syntax improvement over “Option 6”. This
would also seem to eas
On 14/08/2022 01.29, Benedict Elliott Smith wrote:
I’ll do my best to express with my thinking, as well as how I would
explain the feature to a user.
My mental model for LET statements is that they are simply SELECT
statements where the columns that are selected become variables
accessibl
