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. [1] https://docs.microsoft.com/en-us/sql/t-sql/language-elements/else-if-else-transact-sql?view=sql-server-ver16 From: Konstantin Osipov <kos...@scylladb.com> Date: Monday, 13 June 2022 at 14:57 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: CEP-15 multi key transaction syntax > IF (X) THEN > ROLLBACK > RETURN (ERRCODE) > END IF > > or > > IF (X) THEN RAISERROR > > So, that is in essence the question we are currently asking: do > we want to have a more LWT-like approach (and if so, how do we > address this complexity for the user), or do we want a more > SQL-like approach (and if so, how do we modify it to make > non-interactive transactions convenient, and implementation > tractable) > > * This is anyway a shortcoming of existing batches, I think? So > it might be we can sweep it under the rug, but I think it will > be more relevant here as people execute more complex > transactions, and we should ideally have semantics that will > work well into the future – including if we later introduce > interactive transactions. I'd start with answering the question how the syntax should handle NOT FOUND condition. In SQL, that would trigger activation of a CONTINUE handler. It's hard to see how one can truly branch the logic without it. Relying on NULL content of a cell would be full of gotchas. -- Konstantin Osipov, Moscow, Russia
