Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Štefan Miklošovič
We do not have any constraint names so ALTER TABLE ks.table DROP CONSTRAINT a; can not be mistaken for it, but if you insist, this would be better than the alternative: ALTER TABLE ks.table DROP CONSTRAINTS ON column_name; However, that also means that we would have two new reserved words, CONS

Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Yifan Cai
The identifier "a" in the statement "DROP CONSTRAINT a;" might be mistaken for a constraint name. Revising it to "DROP CONSTRAINTS ON a" more clearly conveys the intent of removing all constraints defined on column "a". However, it requires CONSTRAINTS to be added to the reserved keywords. I would

Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Štefan Miklošovič
Thanks Yifan, In your example: ALTER TABLE ks.table DROP CONSTRAINTS ON column_name; I think that "ON" is not necessary. If we compare how a column is dropped: ALTER TABLE ks.table DROP a; Then dropping a constraint would be the same, we would just add "CONSTRAINT" in front of a column name:

Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Yifan Cai
Hi Štefan, The constraint names are to be referenced when altering tables. I like the option you proposed to completely overwrite the column constraints during table alterations, removing the need to declare constraint names. It simplifies the constraint definition. To iterate on the use case of

Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Štefan Miklošovič
I think you need to name the constraints because you want to do something like this, correct? ALTER TABLE keyspace.table ALTER CONSTRAINT [name] CHECK (condition) But that is only necessary when there are multiple constraints on a column and you want to alter either / both of them. If we had

Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Štefan Miklošovič
Thinking about this more .. CREATE TABLE rgb ( name text PRIMARY KEY, r int CONSTRAINED WITH r_value_range_lower_bound CHECK r >= 0 AND r_value_range_upper_bound CHECK r < 256, ... ); What about this: CREATE TABLE rgb ( name text PRIMARY KEY, r int CONSTRAINED WITH r >= 0 AND r < 256, ... ); Wh

Re: [VOTE] CEP-42: Constraints Framework

2024-10-25 Thread Štefan Miklošovič
1.1. CONSTRAINED WITH is good for me 1.2 I prefer 1.1. approach. 2. I am for explicit names over generated ones. I think that the only names which are generated are names for indexes when not specified. 3. I am OK with the exclusion. This is an interesting problem. If somebody wants these two to

Re: [DISCUSS] Modeling JIRA fix version for subprojects

2024-10-25 Thread Brandon Williams
Until someone creates a new design for them, I have changed them to "the eye" like the main project. Kind Regards, Brandon On Thu, Oct 24, 2024 at 5:27 PM Yifan Cai wrote: > > Thanks for working on this! > > Another bikeshed I noticed is the project logo. > > Currently, all of them share the sam