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