Re: Cassandra project biweekly status update 2022-06-14

[Mick Semb Wever]

We've agreed in the past that we want to maintain compatibility and that
> all changes will be done with compatibility in mind (see
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle),
> but we haven't clarified how we make the call on when to bump to next
> major.
>


+1 to always, by default, maintaining compatibility.

Note, a major bump isn't only about compatibility breakages per se, but
a) time to clean up deprecated code, and b) delineating upgrade paths.



> The Release Lifecycle states "Introducing a backward incompatibility
> change needs dev community approval via voting [voting open for 48 hours]."
> But this is under a section called "Outstanding questions beyond the scope
> of this document", maybe it's about time we finalize this and update this
> document?
>


IIRC, though i can easily be wrong, this was meant for breaking changes
within a major, e.g. after a beta release. Not that the same formality
cannot also be applied to trunk dev, as it ensures a desired visibility,
though I wonder if we will solve it in practice most of the time with the
preceding [DISCUSS] thread.

We also have the discussion wrt what are breaking changes. Are we intending
to evolve what interfaces and behaviour we provide, and to what degree,
compatibility over via these discussions/votes?

Re: Cassandra project biweekly status update 2022-06-14

[David Capwell]

This has come up in CASSANDRA-16844, so wanted to bring to a wider audience. 

As of this moment, 3 breaking changes have been detected in 4.1 (1 of them was 
merged into 4.0 as well), and how to resolve this has been talked about a lot, 
so felt its best to have this conversation here.  We've agreed in the past that 
we want to maintain compatibility and that all changes will be done with 
compatibility in mind (see 
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), but 
we haven't clarified how we make the call on when to bump to next major.  The 
Release Lifecycle states "Introducing a backward incompatibility change needs 
dev community approval via voting [voting open for 48 hours]." But this is 
under a section called "Outstanding questions beyond the scope of this 
document", maybe it's about time we finalize this and update this document?

Thanks all!

> On Jun 15, 2022, at 11:05 AM, Dinesh Joshi  wrote:
> 
> Better yet strive to maintain backward compatibility. There are very very few 
> occasions where backward compatibility breakage is warranted. 
> 
>> On Jun 15, 2022, at 10:59 AM, bened...@apache.org wrote:
>> 
>> 
>> > I agree a broader consensus beyond those on the jira ticket should be 
>> > sought before committing the patch that bumps a new major.
>>  
>> Broader consensus should be sought on any ticket that breaks backwards 
>> compatibility – even if we already have bumped major version.
>>  
>> A major version bump should NOT be taken as carte blanche to break users, we 
>> should determine it for eadh case on a balance of benefit/cost.
>>  
>>  
>>  
>> From: Mick Semb Wever 
>> Date: Wednesday, 15 June 2022 at 17:44
>> To: dev@cassandra.apache.org 
>> Subject: Re: Cassandra project biweekly status update 2022-06-14
>> 
>> I'm going to jump off the email list to JIRA for this one - we've had a 
>> discussion ongoing about when we cut a Major vs. a Minor, what qualifies as 
>> an API, etc on CASSANDRA-16844 
>> (https://issues.apache.org/jira/browse/CASSANDRA-16844 
>> ). Expect something 
>> to formally hit the dev mailing list about this soon, but until then we can 
>> keep going on the JIRA ticket.
>>  
>>  
>> I need to take some blame here, for leading people down a bit of a garden 
>> path.
>>  
>> The idea was that trunk is by default the next minor, and that when a patch 
>> lands that warrants a bump to the next major then the patch includes that 
>> change to build.xml's base.version.
>>  
>> The devil is in the detail here, and it becomes a lot more clearer when 
>> reading CASSANDRA-16844.  I'm appreciative when we can tackle these things 
>> in a lazy manner as they arise as real examples often bring that extra 
>> clarity.
>>  
>> I agree a broader consensus beyond those on the jira ticket should be sought 
>> before committing the patch that bumps a new major. The broader audience may 
>> also help propose better solutions that don't require a major change (as was 
>> done in 16844), and help coordinate with other tickets also warranting a new 
>> major…

Re: CEP-15 multi key transaction syntax

[Blake Eggleston]

I think in any scenario where the same cell is updated multiple times, the last 
one would win. The final result for s3 in your example would be 2

> On Jun 16, 2022, at 10:31 AM, Jon Meredith  wrote:
> 
> The reason I brought up static columns was for cases where multiple 
> statements update them and there could be ambiguity.
> 
> CREATE TABLE tbl
> {
>   pk1 int,
>   ck2 int,
>   s3 static int,
>   r4 static int,
>   PRIMARY KEY (pk1, ck2)
> }
> 
> BEGIN TRANSACTION
> UPDATE tbl SET s3=1, r4=1 WHERE pk1=1 AND ck2=1;
> UPDATE tbl SET s3=2, r4=2 WHERE pk1=1 AND ck2=2;
> COMMIT TRANSACTION
> 
> What should the final value be for s3?
> 
> This makes me realize I don't understand how upsert statements that touch the 
> same row would be applied in general within a transaction.
> If the plan is for only-once-per-row within a transaction, then I think 
> regular columns and static columns should be split into their own UPSERT 
> statements.
> 
> On Thu, Jun 16, 2022 at 10:40 AM Benedict Elliott Smith  > wrote:
> I like Postgres' approach of letting you declare an exceptional condition and 
> failing if there is not precisely one result (though I would prefer to 
> differentiate between 0 row->Null and 2 rows->first row), but once you permit 
> coercing to NULL I think you have to then treat it like NULL and permit 
> arithmetic (that itself yields NULL)
> 
> This is explicitly stipulated in ANSI SQL 92, in 6.12  expression>:
> 
> General Rules
> 
>  1) If the value of any  simply contained in a
>  is the null value, then the result of
> the  is the null value.
> 
> 
> On 2022/06/16 16:02:33 Blake Eggleston wrote:
> > Yeah I'd say NULL is fine for condition evaluation. Reference assignment is 
> > a little trickier. Assigning null to a column seems ok, but we should raise 
> > an exception if they're doing math or something that expects a non-null 
> > value
> > 
> > > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith  > > > wrote:
> > > 
> > > AFAICT that standard addresses server-side cursors, not the assignment of 
> > > a query result to a variable. Could you point to where it addresses 
> > > variable assignment?
> > > 
> > > Postgres has a similar concept, SELECT INTO[1], and it explicitly returns 
> > > NULL if there are no result rows, unless STRICT is specified in which 
> > > case an error is returned. My recollection is that T-SQL is also fine 
> > > with coercing no results to NULL when assigning to a variable or using it 
> > > in a sub-expression.
> > > 
> > > I'm in favour of expanding our functionality here, but I do not see 
> > > anything fundamentally problematic about the proposal as it stands.
> > > 
> > > [1] 
> > > https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
> > >  
> > > 
> > > 
> > > 
> > > 
> > > On 2022/06/13 14:52:41 Konstantin Osipov wrote:
> > >> * bened...@apache.org   > >> > [22/06/13 17:37]:
> > >>> I believe that is a MySQL specific concept. This is one problem with 
> > >>> mimicking SQL – it’s not one thing!
> > >>> 
> > >>> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL 
> > >>> value submitted to a Boolean operator yields UNKNOWN.
> > >>> 
> > >>> IF (X) THEN Y does not run Y if X is UNKNOWN;
> > >>> IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
> > >>> 
> > >>> So, I think we have evidence that it is fine to interpret NULL
> > >>> as “false” for the evaluation of IF conditions.
> > >> 
> > >> NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 
> > >> 
> > >> In Cassandra results, there is no way to distinguish null values
> > >> from absence of a row. Branching, thus, without being able to
> > >> branch based on the absence of a row, whatever specific syntax
> > >> is used for such branching, is incomplete. 
> > >> 
> > >> More broadly, SQL/PSM has exception and condition statements, not
> > >> just IF statements.
> > >> 
> > >> -- 
> > >> Konstantin Osipov, Moscow, Russia
> > >> 
> > 
> > 

Re: CEP-15 multi key transaction syntax

[Jon Meredith]

The reason I brought up static columns was for cases where multiple
statements update them and there could be ambiguity.

CREATE TABLE tbl
{
  pk1 int,
  ck2 int,
  s3 static int,
  r4 static int,
  PRIMARY KEY (pk1, ck2)
}

BEGIN TRANSACTION
UPDATE tbl SET s3=1, r4=1 WHERE pk1=1 AND ck2=1;
UPDATE tbl SET s3=2, r4=2 WHERE pk1=1 AND ck2=2;
COMMIT TRANSACTION

What should the final value be for s3?

This makes me realize I don't understand how upsert statements that touch
the same row would be applied in general within a transaction.
If the plan is for only-once-per-row within a transaction, then I think
regular columns and static columns should be split into their own UPSERT
statements.

On Thu, Jun 16, 2022 at 10:40 AM Benedict Elliott Smith 
wrote:

> I like Postgres' approach of letting you declare an exceptional condition
> and failing if there is not precisely one result (though I would prefer to
> differentiate between 0 row->Null and 2 rows->first row), but once you
> permit coercing to NULL I think you have to then treat it like NULL and
> permit arithmetic (that itself yields NULL)
>
> This is explicitly stipulated in ANSI SQL 92, in 6.12  expression>:
>
> General Rules
>
>  1) If the value of any  simply contained in a
>  is the null value, then the result
> of
> the  is the null value.
>
>
> On 2022/06/16 16:02:33 Blake Eggleston wrote:
> > Yeah I'd say NULL is fine for condition evaluation. Reference assignment
> is a little trickier. Assigning null to a column seems ok, but we should
> raise an exception if they're doing math or something that expects a
> non-null value
> >
> > > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> > >
> > > AFAICT that standard addresses server-side cursors, not the assignment
> of a query result to a variable. Could you point to where it addresses
> variable assignment?
> > >
> > > Postgres has a similar concept, SELECT INTO[1], and it explicitly
> returns NULL if there are no result rows, unless STRICT is specified in
> which case an error is returned. My recollection is that T-SQL is also fine
> with coercing no results to NULL when assigning to a variable or using it
> in a sub-expression.
> > >
> > > I'm in favour of expanding our functionality here, but I do not see
> anything fundamentally problematic about the proposal as it stands.
> > >
> > > [1]
> https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
> > >
> > >
> > >
> > > On 2022/06/13 14:52:41 Konstantin Osipov wrote:
> > >> * bened...@apache.org  [22/06/13 17:37]:
> > >>> I believe that is a MySQL specific concept. This is one problem with
> mimicking SQL – it’s not one thing!
> > >>>
> > >>> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a
> NULL value submitted to a Boolean operator yields UNKNOWN.
> > >>>
> > >>> IF (X) THEN Y does not run Y if X is UNKNOWN;
> > >>> IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
> > >>>
> > >>> So, I think we have evidence that it is fine to interpret NULL
> > >>> as “false” for the evaluation of IF conditions.
> > >>
> > >> NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 
> > >>
> > >> In Cassandra results, there is no way to distinguish null values
> > >> from absence of a row. Branching, thus, without being able to
> > >> branch based on the absence of a row, whatever specific syntax
> > >> is used for such branching, is incomplete.
> > >>
> > >> More broadly, SQL/PSM has exception and condition statements, not
> > >> just IF statements.
> > >>
> > >> --
> > >> Konstantin Osipov, Moscow, Russia
> > >>
> >
> >
>

Re: CEP-15 multi key transaction syntax

[Benedict Elliott Smith]

I like Postgres' approach of letting you declare an exceptional condition and 
failing if there is not precisely one result (though I would prefer to 
differentiate between 0 row->Null and 2 rows->first row), but once you permit 
coercing to NULL I think you have to then treat it like NULL and permit 
arithmetic (that itself yields NULL)

This is explicitly stipulated in ANSI SQL 92, in 6.12 :

General Rules

 1) If the value of any  simply contained in a
 is the null value, then the result of
the  is the null value.


On 2022/06/16 16:02:33 Blake Eggleston wrote:
> Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a 
> little trickier. Assigning null to a column seems ok, but we should raise an 
> exception if they're doing math or something that expects a non-null value
> 
> > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith  
> > wrote:
> > 
> > AFAICT that standard addresses server-side cursors, not the assignment of a 
> > query result to a variable. Could you point to where it addresses variable 
> > assignment?
> > 
> > Postgres has a similar concept, SELECT INTO[1], and it explicitly returns 
> > NULL if there are no result rows, unless STRICT is specified in which case 
> > an error is returned. My recollection is that T-SQL is also fine with 
> > coercing no results to NULL when assigning to a variable or using it in a 
> > sub-expression.
> > 
> > I'm in favour of expanding our functionality here, but I do not see 
> > anything fundamentally problematic about the proposal as it stands.
> > 
> > [1] 
> > https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
> > 
> > 
> > 
> > On 2022/06/13 14:52:41 Konstantin Osipov wrote:
> >> * bened...@apache.org  [22/06/13 17:37]:
> >>> I believe that is a MySQL specific concept. This is one problem with 
> >>> mimicking SQL – it’s not one thing!
> >>> 
> >>> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL 
> >>> value submitted to a Boolean operator yields UNKNOWN.
> >>> 
> >>> IF (X) THEN Y does not run Y if X is UNKNOWN;
> >>> IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
> >>> 
> >>> So, I think we have evidence that it is fine to interpret NULL
> >>> as “false” for the evaluation of IF conditions.
> >> 
> >> NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 
> >> 
> >> In Cassandra results, there is no way to distinguish null values
> >> from absence of a row. Branching, thus, without being able to
> >> branch based on the absence of a row, whatever specific syntax
> >> is used for such branching, is incomplete. 
> >> 
> >> More broadly, SQL/PSM has exception and condition statements, not
> >> just IF statements.
> >> 
> >> -- 
> >> Konstantin Osipov, Moscow, Russia
> >> 
> 
> 

Re: CEP-15 multi key transaction syntax

[Blake Eggleston]

Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a 
little trickier. Assigning null to a column seems ok, but we should raise an 
exception if they're doing math or something that expects a non-null value

> On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith  
> wrote:
> 
> AFAICT that standard addresses server-side cursors, not the assignment of a 
> query result to a variable. Could you point to where it addresses variable 
> assignment?
> 
> Postgres has a similar concept, SELECT INTO[1], and it explicitly returns 
> NULL if there are no result rows, unless STRICT is specified in which case an 
> error is returned. My recollection is that T-SQL is also fine with coercing 
> no results to NULL when assigning to a variable or using it in a 
> sub-expression.
> 
> I'm in favour of expanding our functionality here, but I do not see anything 
> fundamentally problematic about the proposal as it stands.
> 
> [1] 
> https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
> 
> 
> 
> On 2022/06/13 14:52:41 Konstantin Osipov wrote:
>> * bened...@apache.org  [22/06/13 17:37]:
>>> I believe that is a MySQL specific concept. This is one problem with 
>>> mimicking SQL – it’s not one thing!
>>> 
>>> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL 
>>> value submitted to a Boolean operator yields UNKNOWN.
>>> 
>>> IF (X) THEN Y does not run Y if X is UNKNOWN;
>>> IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
>>> 
>>> So, I think we have evidence that it is fine to interpret NULL
>>> as “false” for the evaluation of IF conditions.
>> 
>> NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 
>> 
>> In Cassandra results, there is no way to distinguish null values
>> from absence of a row. Branching, thus, without being able to
>> branch based on the absence of a row, whatever specific syntax
>> is used for such branching, is incomplete. 
>> 
>> More broadly, SQL/PSM has exception and condition statements, not
>> just IF statements.
>> 
>> -- 
>> Konstantin Osipov, Moscow, Russia
>> 

Re: CEP-15 multi key transaction syntax

[Benedict Elliott Smith]

AFAICT that standard addresses server-side cursors, not the assignment of a 
query result to a variable. Could you point to where it addresses variable 
assignment?

Postgres has a similar concept, SELECT INTO[1], and it explicitly returns NULL 
if there are no result rows, unless STRICT is specified in which case an error 
is returned. My recollection is that T-SQL is also fine with coercing no 
results to NULL when assigning to a variable or using it in a sub-expression.

I'm in favour of expanding our functionality here, but I do not see anything 
fundamentally problematic about the proposal as it stands.

[1] 
https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW



On 2022/06/13 14:52:41 Konstantin Osipov wrote:
> * bened...@apache.org  [22/06/13 17:37]:
> > I believe that is a MySQL specific concept. This is one problem with 
> > mimicking SQL – it’s not one thing!
> > 
> > In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL 
> > value submitted to a Boolean operator yields UNKNOWN.
> > 
> > IF (X) THEN Y does not run Y if X is UNKNOWN;
> > IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
> > 
> > So, I think we have evidence that it is fine to interpret NULL
> > as “false” for the evaluation of IF conditions.
> 
> NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 
> 
> In Cassandra results, there is no way to distinguish null values
> from absence of a row. Branching, thus, without being able to
> branch based on the absence of a row, whatever specific syntax
> is used for such branching, is incomplete. 
> 
> More broadly, SQL/PSM has exception and condition statements, not
> just IF statements.
> 
> -- 
> Konstantin Osipov, Moscow, Russia
> 

Re: CEP-15 multi key transaction syntax

[Blake Eggleston]

I see what you mean. We have the EXISTS/NOT EXISTS condition for explicitly 
checking for the existence of a row. One thing the old syntax did is how it 
handled references to columns that don't exist. Previously, if any column 
reference didn't resolve, the update wouldn't apply. With the new syntax, if we 
want to be able to use multiple branches, that's going to be more difficult, 
since taking the 'ELSE' path may not make sense from an application 
perspective. So returning an exception in that case might be the right thing to 
do

> On Jun 15, 2022, at 2:18 PM, Konstantin Osipov  
> wrote:
> 
> * bened...@apache.org  [22/06/16 00:00]:
>> First some history: static rows are an efficiency sop to those
>> who migrated from the historical wide row world, where you could
>> have “global” partition state fetched with every query, and to
>> support the deprecation of thrift and its horrible data model
>> something needed to give – static rows were the result.
>> 
>> However, is the concept generally consistent? I think so. At
>> least, your example seem fine to me, and I can’t see how they
>> violate the “relational model” (whatever that may be). If it
>> helps, you can think of the static columns actually creating a
>> second table, so that you now have two separate tables with the
>> same partition key. These tables are implicitly related via a
>> “full outer join” on the partition key, and you can imagine that
>> you are generally querying a view of this relation.
> 
> This is a model I haven't pondered yet. 
> 
>> In this case, you would expect the outcome you see AFAICT. If
>> you have no restriction on the results, and you have no regular
>> rows and one static row, you would see a single static row
>> result with null regular columns (and a count of 1 row). If you
>> imposed a restriction on regular columns, you would not see the
>> static column as the null regular columns would not match the
>> condition.
>> 
>>> In LWT, a static row appears to exist when there is no regular row matching 
>>> WHERE
>> 
>> I assume you mean the IF clause matches against a static row if
>> you UPDATE tbl SET v = a WHERE p = b IF s = c. This could be an
>> inconsistency, but I think it is not. Recall, UPDATE in CQL is
>> not UPDATE in SQL. SQL would do nothing if the row doesn’t
>> exist, whatever the IF clause might say. CQL is really
>> performing UPSERT.
>> 
>> So, what happens when the WHERE clause doesn’t match a primary
>> key with UPSERT? A row is created. In this case, if you consider
>> that this empty nascent row is used to join with the static
>> “table” for evaluating the IF condition, to decide what you
>> UPSERT, then it all makes sense – to me, anyway.
>> 
>>> NULLs are first-class values, distinguishable from unset values
>> 
>> Could you give an example?
> 
> In SQL, if you FETCH into a VARIABLE and there is no matching row, 
> it won't quietly fill your variable with NULLs or a static cells,
> and leave you wondering what to do next. FETCH will RAISE NOT
> FOUND condition, a kind of exception you can handle separately. 
> Totally different in Cassandra where NULL is a deletion marker and
> NULLs are indistinguishable from missing values.
> 
> -- 
> Konstantin Osipov, Moscow, Russia

Re: CEP-15 multi key transaction syntax

[Konstantin Osipov]

* bened...@apache.org  [22/06/16 00:00]:
> First some history: static rows are an efficiency sop to those
> who migrated from the historical wide row world, where you could
> have “global” partition state fetched with every query, and to
> support the deprecation of thrift and its horrible data model
> something needed to give – static rows were the result.
> 
> However, is the concept generally consistent? I think so. At
> least, your example seem fine to me, and I can’t see how they
> violate the “relational model” (whatever that may be). If it
> helps, you can think of the static columns actually creating a
> second table, so that you now have two separate tables with the
> same partition key. These tables are implicitly related via a
> “full outer join” on the partition key, and you can imagine that
> you are generally querying a view of this relation.

This is a model I haven't pondered yet. 

> In this case, you would expect the outcome you see AFAICT. If
> you have no restriction on the results, and you have no regular
> rows and one static row, you would see a single static row
> result with null regular columns (and a count of 1 row). If you
> imposed a restriction on regular columns, you would not see the
> static column as the null regular columns would not match the
> condition.
> 
> > In LWT, a static row appears to exist when there is no regular row matching 
> > WHERE
> 
> I assume you mean the IF clause matches against a static row if
> you UPDATE tbl SET v = a WHERE p = b IF s = c. This could be an
> inconsistency, but I think it is not. Recall, UPDATE in CQL is
> not UPDATE in SQL. SQL would do nothing if the row doesn’t
> exist, whatever the IF clause might say. CQL is really
> performing UPSERT.
> 
> So, what happens when the WHERE clause doesn’t match a primary
> key with UPSERT? A row is created. In this case, if you consider
> that this empty nascent row is used to join with the static
> “table” for evaluating the IF condition, to decide what you
> UPSERT, then it all makes sense – to me, anyway.
> 
> > NULLs are first-class values, distinguishable from unset values
> 
> Could you give an example?

In SQL, if you FETCH into a VARIABLE and there is no matching row, 
it won't quietly fill your variable with NULLs or a static cells,
and leave you wondering what to do next. FETCH will RAISE NOT
FOUND condition, a kind of exception you can handle separately. 
Totally different in Cassandra where NULL is a deletion marker and
NULLs are indistinguishable from missing values.

-- 
Konstantin Osipov, Moscow, Russia

Re: CEP-15 multi key transaction syntax

[Konstantin Osipov]

* bened...@apache.org  [22/06/13 17:37]:
> I believe that is a MySQL specific concept. This is one problem with 
> mimicking SQL – it’s not one thing!
> 
> In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL value 
> submitted to a Boolean operator yields UNKNOWN.
> 
> IF (X) THEN Y does not run Y if X is UNKNOWN;
> IF (X) THEN Y ELSE Z does run Z if X is UNKNOWN.
> 
> So, I think we have evidence that it is fine to interpret NULL
> as “false” for the evaluation of IF conditions.

NOT FOUND handler is in ISO/IEC 9075-4:2003 13.2 

In Cassandra results, there is no way to distinguish null values
from absence of a row. Branching, thus, without being able to
branch based on the absence of a row, whatever specific syntax
is used for such branching, is incomplete. 

More broadly, SQL/PSM has exception and condition statements, not
just IF statements.

-- 
Konstantin Osipov, Moscow, Russia