Add support for CHECK constraint in INSERT statement in engine and SPI

[ebyhr]

Description

Add support for CHECK constraint in INSERT statement to engine and SPI.

Release notes

(x) Release notes are required, with the following suggested text:

# General
* Add support for `CHECK` constraints in `INSERT` statement. ({issue}`14964`)

[ebyhr]

CI hit #14441

[findepi]

Do we need this here? Why?

[ebyhr]

To use from StatementAnalyzer. I would add a new method in Metadata if it's better than here. Or are you suggesting moving to the under column?

[findepi]

Feels like not belonging here at all. I'd like to understand this more.

[findepi]

Feels like it needs to stay here (or we would have to remove almost all usages of getTableSchema and migrate them to getTableMetadata)

[findepi]

Can we also have planner tests that assert actual plans?

@martint @kasiafi would it be a good idea here?

[electrum]

Do we want to enforce that the check expression does not contain subqueries?

[ebyhr]

I think so. Changed to deny an expression having subqueries.

[findepi]

Feels like it needs to stay here (or we would have to remove almost all usages of getTableSchema and migrate them to getTableMetadata)

[findepi]

analyzeRowFilter technically does more or less what we want -- it takes a String expression and produces an Expression.
However, the method name and checks done in that method (e.g. analysis.hasRowFilter(name, currentIdentity) or analysis.registerTableForRowFiltering(name, currentIdentity)) are not applicable to check constraints.

Let's rollback changes to analyzeRowFilter.
Let's extract common code for converting connector-provided String into Expression (with due verifications).

[findepi]

"Check constraint violation: " + predicate ?

what does eg PostgreSQL print?
what does MySQL print?

[ebyhr]

Here's the error message.

PostgreSQL

tpch=# create table test (c1 int check (c1 > 0));
tpch=# insert into test values (-1);
ERROR:  new row for relation "test" violates check constraint "test_c1_check"
DETAIL:  Failing row contains (-1).

MySQL

mysql> create table test (c1 int, check (c1 > 0));
mysql> insert into test values (-1);
ERROR 3819 (HY000): Check constraint 'test_chk_1' is violated.

[findepi]

I like ours better, since it mentions the check formula. (we don't have a check name, and maybe we don't need one for error reporting)
I don't think we could do this for row filters, but i think we can do this for check constraints.

[findepi]

for inserts/update/merge, the name addRowConstraints would be better.
Row filters become "row constraints", that's fine.
(the opposite, calling "check constraints" a "row filter" doesn't sound right)

[findepi]

Can we simply keep the old constructor as deprecated?

[ebyhr]

CI core/trino-main hit #12627. Going to push an empty commit.

[findepi]

I like ours better, since it mentions the check formula. (we don't have a check name, and maybe we don't need one for error reporting)
I don't think we could do this for row filters, but i think we can do this for check constraints.

[findepi]

Let's make the new one experimental and remove deprecation. For now. We will add deprecation when the new one is no longer experimental.

[ebyhr]

Addressed comments and added tests for other statements, UPDATE, MERGE and DELETE.

[ebyhr]

Rebased on upstream to resolve conflicts.

[martint]

Why was checkConstraints added to this method? They don't belong here. This method is specifically about masks and filters on a source table, and check constraints are none of that. They don't even apply to a source table, only to the target of an insert or update.

[martint]

Revert this. This is spurious reuse of functionality. We don't need to add an abstraction for a "row constraint expression". It's a bit of a stretch to call row filters and check constraints "constraint expressions"

[martint]

There's nothing special about a "row constraint" in this method. If anything, it should be called coerceToBoolean, but it also feels like spurious reuse of code.

[martint]

As I mentioned above, row filters and check constraints are two difference concepts. Let's not mix them up.

[ebyhr]

Fixing CI failures.

[ebyhr]

@martint Thanks for your review. Addressed comments.

[ebyhr]

Rebased on upstream to resolve conflicts.

[ebyhr]

@martint Gentle reminder.

[ebyhr]

@martint Gentle reminder.

[ebyhr]

Rebased on upstream to resolve conflicts.

[findepi]

wrap in unmodifiableList

[findepi]

Nice!

[findepi]

My intellij formatter would put an empty line before @return line. Would yours too?

[findepi]

follow up airlift/airbase#338

[findepi]

My intellij formatter would put an empty line before @return line. Would yours too?

[findepi]

Is this coercion getting applied?
(see #15744)

[findepi]

"should not contain temporal expression"
or "should not be time-dependent"

[findepi]

nit: can import isDeterministic statically

[ebyhr]

trino-redis hit #13779

[ebyhr]

I will merge this PR tomorrow if there's no objection.

[martint]

Ok, that makes sense. Please add that short explanation to the commit message so it doesn't get lost.

[martint]

This is the wrong error code. Check constraints are not row filters.

[martint]

EXPRESSION_NOT_IN_DISTINCT is the wrong error code for this.

[martint]

Using filter for the argument name is a little misleading. Rename it to constraint

[martint]

What's "predicate transformation"?

[ebyhr]

That's a function inserting an expression to fail when the constraint is violated. Do you have any suggestions for the new variable name?

    private static Function<Expression, Expression> failIfCheckConstraintIsNotMet(Metadata metadata, Session session)
    {
        return predicate -> new IfExpression(
                // When predicate evaluates to UNKNOWN (e.g. NULL > 100), it should not violate the check constraint.
                new CoalesceExpression(predicate, TRUE_LITERAL),
                TRUE_LITERAL,
                new Cast(failFunction(metadata, session, CONSTRAINT_VIOLATION, "Check constraint violation: " + predicate), toSqlType(BOOLEAN)));
    }

[martint]

I'm not sure that abstraction is even necessary. Why not inline that logic directly in addCheckConstraints?

[martint]

I.e., just modify addCheckConstraints to do this:

public RelationPlan addCheckConstraints(List<Expression> constraints, Table node, RelationPlan plan, Function<Table, Scope> accessControlScope)
{
    ...
    for (Expression constraint : constraints) {
        ...

        Expression predicate = new IfExpression(
                // When predicate evaluates to UNKNOWN (e.g. NULL > 100), it should not violate the check constraint.
                new CoalesceExpression(coerceIfNecessary(analysis, constraint, planBuilder.rewrite(constraint)), TRUE_LITERAL),
                TRUE_LITERAL,
                new Cast(failFunction(plannerContext.getMetadata(), session, CONSTRAINT_VIOLATION, "Check constraint violation: " + predicate), toSqlType(BOOLEAN)));

        planBuilder = planBuilder.withNewRoot(new FilterNode(
                idAllocator.getNextId(),
                planBuilder.getRoot(),
                predicate));
    }

    ...
}

[ebyhr]

@martint Agree with inline. Updated.

[martint]

Similarly as above, the name filters is misleading. Rename it to constraints.

[martint]

assertThat(assertions.query(...))
    .matches(...)

[martint]

Use text blocks

[martint]

Format as:

       assertThatThrownBy(() -> assertions.query("""
                MERGE INTO mock.tiny.nation 
                USING (VALUES 42) t(dummy) 
                ON false
                WHEN NOT MATCHED THEN 
                    INSERT VALUES (101, 'POLAND', 0, 'No comment')
                """))
                .hasMessage("line 1:1: Cannot merge into a table with check constraints");

[ebyhr]

@martint Addressed comments.

[martint]

assertThat(assertions.query(...), here and everywhere else in this file