As Yifan already said, "check" is not a reserved word now and its usage
does not collide with anything.
If people have columns, tables, keyspaces with name "check" that seems to
work already so they don't need to do anything:
CREATE TABLE ks.tb (id int check id > 0, val int check val > 0, primary key
(id));
ALTER TABLE ks.tb ADD check int check check > 0;
DESCRIBE ks.tb;
CREATE TABLE ks.tb (
id int CHECK id > 0 PRIMARY KEY,
check int CHECK check > 0,
val int CHECK val > 0
) ....
CREATE TABLE ks.check (id int check id > 0, check int check check > 0,
primary key (id));
CREATE KEYSPACE check WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
CREATE TABLE check.check (check int check check > 0, val int check val > 0,
primary key (check));
INSERT INTO check.check (check , val ) VALUES ( 1, 1);
PostgreSQL has this:
CREATE TABLE products (
product_no integer,
name text,
price numeric CHECK (price > 0)
);
we follow this approach (minus parenthesis). We can also chain constraints
whatever we like
val int CHECK val > 0 and age < 100
We can make a stab in trying to model
val int not null check val > 0
this is how PostgreSQL has it (1).
but that would be more complicated on the implementation side because we
would need to also accommodate "CQL describe" to dump it like that, plus I
am not sure how complicated it would be to tweak the parser as well.
I will try to make some progress and will report back.
Regards
(1)
https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-NOT-NULL
On Sun, Apr 13, 2025 at 6:49 PM Dinesh Joshi <djo...@apache.org> wrote:
> On Sun, Apr 13, 2025 at 9:24 AM Patrick McFadin <pmcfa...@gmail.com>
> wrote:
>
>> I'm loving all the syntax discussion lately. It's a good debate and
>> essential for the project's future with a good developer experience.
>>
>
> +1
>
>
>> On NULL. I've been asked this a million times by end users. Why is there
>> no "NOT NULL" in the schema?
>>
>
> I would've expected this to be in billions by now ;)
>
>
>> I'm in favor of the standard SQL syntax here because it's what users have
>> been using forever:
>> name text NOT NULL
>>
>
> I hold a weak opinion on this. We don't have to necessarily align on to
> the standard SQL syntax. In my experience, users subconsciously feel
> Cassandra is a SQL database and try to design their schema to fit the
> traditional SQL / RDBMS design and then later are disappointed to find out
> it doesn't have joins or foreign key constraints. But that's just my
> personal experience working with users. However, I think we should strive
> for consistency and if it aligns with SQL I have no issues with the syntax.
> Just sharing my experience.
>
>
>> On CHECK. Also in favor of making this a reserved word but in context.
>> Namely, how Postgres SQL works. CHECK ( boolean_expression_on_column)
>>
>
> Making CHECK a reserved keyword may result in issues that Scott described.
> It will present a substantial barrier for users to upgrade as applications
> will have to be updated.
>
> Thanks,
>
> Dinesh
>
