_If we aren’t matching the feature, why are we matching the keyword?_

??? Nobody said that if we do not use the exact same feature we have to
rename it.

On Fri, Apr 11, 2025 at 6:13 PM Benedict <bened...@apache.org> wrote:

> [image: elephant.png]
>
> 5.5. Constraints
> <https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS>
> postgresql.org
> <https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS>
>
> <https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS>
>
>
> See the note directly above section 5.5.2 - Postgres supports functions in
> the CHECK predicate and requires they are pure functions (ie always yield
> the same result).
>
> The point is, CHECK is consistently a predicate defined over a field
> expression. If we aren’t matching the feature, why are we matching the
> keyword?
>
> I also disagree that CHECK is a useful prefix to all constraints, and
> would prefer consistency with Postgres here that also uses plain NOT NULL
> for a NOT NULL constraint.
>
>
> On 11 Apr 2025, at 17:05, Štefan Miklošovič <smikloso...@apache.org>
> wrote:
>
> 
> I went through Postgres' docs in a quite elaborate manner and I do not see
> any usage of "constraint functions" as we have them. Both MySQL and
> Postgres seem to only provide simple predicates (using relational
> operators) and "functions" as we have them (e.g. json / length) are not
> supported. So in this regard we are providing more than they do. Where have
> you taken "is_json(field)" form from? Not saying it's wrong, I am just
> curious where this is coming from.
>
> I do not like that we would have "NOT NULL" without "CHECK". I think we
> can go a little bit our own way as we have the comfort of modelling this
> from scratch. CQL is already different from SQL as is and I do not think
> that trying to follow SQL _orthodoxly_ is absolutely necessary but at the
> same time I find it easier and more welcoming for users coming to Cassandra
> for the first time to have syntax which is as close as possible to what
> they are used to.
>
> I find having constraints starting with "CHECK" _every time_ consistent.
> They do not need to think twice if "check" is going to be there or not. It
> is there every time. I do not know why SQL did not do it the same way, most
> probably because "NOT NULL" was the first being introduced and "CHECK"
> followed afterwards and it was just too late to it consistent.
>
>
>
> On Fri, Apr 11, 2025 at 5:33 PM Bernardo Botella <
> conta...@bernardobotella.com> wrote:
>
>> Benedict:
>>
>> An alternative for that, keeping the CHECK word, would be to change the
>> constraint name to IS_JSON. CHECK IS_JSON would read as you intend without
>> the need to jump to REQUIRE. I think that’s true for the rest of provided
>> constraints as well.
>>
>> Bernardo
>>
>>
>> On Apr 11, 2025, at 6:02 AM, Benedict <bened...@apache.org> wrote:
>>
>> We have taken a different approach though, as we do not actually take a
>> predicate on the RHS and do not supply the column name. In our examples we
>> had eg CHECK JSON, which doesn’t parse unambiguously to a human. The
>> equivalent to Postgres would seem to be CHECK is_json(field).
>>
>> I’m all for following an existing example, but once we decide to diverge
>> the justification is gone and we should decide holistically what we think
>> is best. So if we want to elide the column entirely and have a list of
>> built in restrictions, I’d prefer eg REQUIRE JSON since this parses
>> unambiguously to a human, whereas if we want to follow Postgres let’s do
>> that but do it but that means eg CHECK is_json(field).
>>
>> On 11 Apr 2025, at 10:57, Štefan Miklošovič <smikloso...@apache.org>
>> wrote:
>>
>> 
>> While modelling that, we followed how it is done in SQL world, PostgreSQL
>> as well as MySQL both use CHECK.
>>
>>
>> https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS
>>
>> https://dev.mysql.com/doc/refman/8.4/en/create-table-check-constraints.html
>>
>> On Fri, Apr 11, 2025 at 10:43 AM Benedict <bened...@apache.org> wrote:
>>
>>> I would prefer require/expect/is over check
>>>
>>> On 11 Apr 2025, at 08:05, Štefan Miklošovič <smikloso...@apache.org>
>>> wrote:
>>>
>>> 
>>> Yes, you will have it like that :) Thank you for this idea. Great
>>> example of cooperation over diverse domains.
>>>
>>> On Fri, Apr 11, 2025 at 12:29 AM David Capwell <dcapw...@apple.com>
>>> wrote:
>>>
>>>> I am biased but I do prefer
>>>>
>>>> val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024
>>>>
>>>> Here is a similar accord CQL
>>>>
>>>> BEGIN TRANSACTION
>>>>   LET a = (…);
>>>>   IF a IS NOT NULL
>>>>       AND a.b IS NOT NULL
>>>>       AND a.c IS NULL; THEN
>>>>     — profit
>>>>   END IF
>>>> COMMIT TRANSACTION
>>>>
>>>> On Apr 10, 2025, at 8:46 AM, Yifan Cai <yc25c...@gmail.com> wrote:
>>>>
>>>> Re: reserved keywords, “check” is currently not, and I don’t think it
>>>> needs to be a reserved keyword with the proposal.
>>>>
>>>> ------------------------------
>>>> *From:* C. Scott Andreas <sc...@paradoxica.net>
>>>> *Sent:* Thursday, April 10, 2025 7:59:35 AM
>>>> *To:* dev@cassandra.apache.org <dev@cassandra.apache.org>
>>>> *Cc:* dev@cassandra.apache.org <dev@cassandra.apache.org>
>>>> *Subject:* Re: Constraint's "not null" alignment with transactions and
>>>> their simplification
>>>>
>>>> If the proposal does not introduce “check” as a reserved keyword that
>>>> would require quoting in existing DDL/DML, this concern doesn’t apply and
>>>> the email below can be ignored. This might be the case if “CHECK NOT NULL”
>>>> is the full token introduced rather than “CHECK” separately from
>>>> constraints that are checked.
>>>>
>>>> If “check” is introduced as a standalone reserved keyword: my primary
>>>> feedback is on the introduction of reserved words in the CQL grammar that
>>>> may affect compatibility of existing schemas.
>>>>
>>>> In the Cassandra 3.x series, several new CQL reserved words were added
>>>> (more than necessary) and subsequently backed out, because it required
>>>> users to begin quoting schemas and introduced incompatibility between 3.x
>>>> and 4.x for queries and DDL that “just worked” before.
>>>>
>>>> The word “check” is used in many domains (test/evaluation engineering,
>>>> finance, business processes, etc) and is likely to be used in user schemas.
>>>> If the proposal introduces this as a reserved word that would require it to
>>>> be quoted if used in table or column names, this will create
>>>> incompatibility for existing user queries on upgrade.
>>>>
>>>> Otherwise, ignore me. :)
>>>>
>>>> Thanks,
>>>>
>>>> – Scott
>>>>
>>>> –––
>>>> Mobile
>>>>
>>>> On Apr 10, 2025, at 7:47 AM, Jon Haddad <j...@rustyrazorblade.com>
>>>> wrote:
>>>>
>>>> 
>>>> This looks like a really nice improvement to me.
>>>>
>>>>
>>>> On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič <
>>>> smikloso...@apache.org> wrote:
>>>>
>>>> Recently, David Capwell was commenting on constraints in one of Slack
>>>> threads (1) in dev channel and he suggested that the current form of "not
>>>> null" constraint we have right now in place, e.g like this
>>>>
>>>> create table ks.tb (id int primary key, val int check not_null(val));
>>>>
>>>> could be instead of that form used like this:
>>>>
>>>> create table ks.tb (id int primary key, val int check not null);
>>>>
>>>> That is - without the name of a column in the constraint's argument.
>>>> The reasoning behind that was that it is not only easier to read but there
>>>> is also this concept in transactions (cep-15) where there is also "not
>>>> null" used in some fashion and it would be nice if this was aligned so a
>>>> user does not encounter two usages of "not null"-s which are written down
>>>> differently, syntax-wise.
>>>>
>>>> Could the usage of "not null" in transactions be confirmed?
>>>>
>>>> This rather innocent suggestion brought an idea to us that constraints
>>>> could be quite simplified when it comes to their syntax, consider this:
>>>>
>>>> val int check not_null(val)
>>>> val text check json(val)
>>>> val text check lenght(val) < 1000
>>>>
>>>> to be used like this:
>>>>
>>>> val int check not null
>>>> val text check json
>>>> val text check length() < 1000
>>>>
>>>> more involved checks like this:
>>>>
>>>> val text check not_null(val) and json(val) and length(val) < 1000
>>>>
>>>> might be just simplified to:
>>>>
>>>> val text check not null and json and length() < 1000
>>>>
>>>> It almost reads like plain English. Isn't this just easier for an eye?
>>>>
>>>> The reason we kept the column names in constraint definitions is that,
>>>> frankly speaking, we just did not know any better at the time it was about
>>>> to be implemented. It is a little bit more tricky to be able to use it
>>>> without column names because in Parser.g / Antlr we just bound the grammar
>>>> around constraints to a column name directly there. When column names are
>>>> not going to be there anymore, we need to bind it later in the code behind
>>>> the parser in server code. It is doable, it was just about being a little
>>>> bit more involved there.
>>>>
>>>> Also, one reason to keep the name of a column was that we might specify
>>>> different columns in a constraint from a column that is defined on to have
>>>> cross-column constraints but we abandoned this idea altogether for other
>>>> reasons which rendered the occurrence of a column name in a constraint
>>>> definition redundant.
>>>>
>>>> To have some overview of what would be possible to do with this
>>>> proposal:
>>>>
>>>> val3 text CHECK SOMECONSTRAINT('a');
>>>> val3 text CHECK JSON;
>>>> val3 text CHECK SOMECONSTRAINT('a') > 1;
>>>> val3 text CHECK SOMECONSTRAINT('a', 'b', 'c') > 1;
>>>> val3 text CHECK JSON AND LENGTH() < 600;
>>>> afternoon time CHECK afternoon >= '12:00:00' AND afternoon =<
>>>> '23:59:59';
>>>> val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024
>>>>
>>>> In addition to the specification of constraints without columns, what
>>>> would be possible to do is to also specify arguments to constraints. It is
>>>> currently not possible and there is no constraint which would accept
>>>> arguments to its function but I think that to be as flexible as possible
>>>> and prepare for the future, we might implement it as well.
>>>>
>>>> Constraints in their current form are already usable however I just
>>>> think that if we do not simplify, align and extend the syntax right now,
>>>> before it is baked in in a release, then we will never do it as it will be
>>>> quite tricky to extend this without breaking it and maintaining two
>>>> grammars at the same time would be very complex if not flat out impossible.
>>>>
>>>> Are you open to the simplification of constraint definitions as
>>>> suggested and what is your feedback about that? I already have a working
>>>> POC which just needs to be polished and tests fixed to accommodate the new
>>>> approach.
>>>>
>>>> Regards
>>>>
>>>> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1742409054164389
>>>>
>>>>
>>>>
>>

Reply via email to