[ 
https://issues.apache.org/jira/browse/CALCITE-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109229#comment-18109229
 ] 

zzwqqq commented on CALCITE-7627:
---------------------------------

https://github.com/apache/calcite/pull/5211 adds an EnumerableCalc below 
EnumerableTableModify for INSERT and UPDATE. It checks bounded character and 
binary values and applies target casts for exact numeric assignments.

During review, [~mbudiu] noted that systems may have different assignment 
rules. For example, some may reject BC dates or reduce timestamp precision. 
Applications could replace EnumerableTableModifyRule when they need different 
behavior. Another option is to let the rule accept an interface with per-type 
hooks. It is not yet clear what that API should look like.

Should this PR keep the current implementation as the default and rely on rule 
replacement for customization? Or should we design a per-type hook first and 
implement the checks through it?

> Enumerable DML should reject assignments that may lose data
> -----------------------------------------------------------
>
>                 Key: CALCITE-7627
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7627
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: zzwqqq
>            Assignee: zzwqqq
>            Priority: Major
>              Labels: pull-request-available
>
> Enumerable DML currently accepts some assignments that may lose data.
> One example is assigning a longer string to a shorter VARCHAR column:
> {code:sql}
> CREATE TABLE dept (deptno INTEGER NOT NULL, name VARCHAR(10));
> INSERT INTO dept
> VALUES (30, 'Engineering');
> {code}
> The Enumerable/server path can insert the value now. With their default 
> settings, PostgreSQL, MySQL, and Oracle reject this case:
> https://onecompiler.com/postgresql/44sf3dz68
> https://onecompiler.com/mysql/44sf3efz4
> https://onecompiler.com/oracle/44sf3ewmh
> The assignment should produce a runtime error rather than truncating or 
> accepting the value.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to