[ 
https://issues.apache.org/jira/browse/DERBY-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781968#action_12781968
 ] 

Knut Anders Hatlen commented on DERBY-4451:
-------------------------------------------

If I understand correctly, the patch will disallow DEFAULT in 
EXCEPT/INTERSECT/UNION, but only for the queries that end up calling 
ResultSetNode.forbidGenerationOverrides(). This means that it will be 
disallowed if the DEFAULT is specified for a generated column (not for identity 
columns or regular columns), and an explicit column list is specified. So given 
a table

  CREATE TABLE T(A INT, B GENERATED ALWAYS AS (-A));

the following is disallowed:

  INSERT INTO T(B) VALUES (DEFAULT) UNION VALUES (DEFAULT);
  INSERT INTO T(A, B) VALUES (DEFAULT, DEFAULT) UNION VALUES (DEFAULT, DEFAULT);

whereas this is still allowed:

  INSERT INTO T(A) VALUES (DEFAULT) UNION VALUES (DEFAULT);
  INSERT INTO T VALUES (DEFAULT, DEFAULT) UNION VALUES (DEFAULT, DEFAULT);

Is that about right? If so, using this mechanism to disallow DEFAULT seems to 
miss most cases, so perhaps it's the wrong place to add this check? Since the 
checking makes the patch somewhat more complex, and it is not actually needed 
for this issue (is it?), perhaps it's better to leave it out and try do devise 
a complete fix in DERBY-4426 instead?

> ArrayIndexOutOfBoundsException or ASSERT FAILED when inserting generated 
> columns out of order
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4451
>                 URL: https://issues.apache.org/jira/browse/DERBY-4451
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.3.0, 10.6.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Dag H. Wanvik
>         Attachments: derby-4451.diff, derby-4451.stat, derby-4451b.diff, 
> derby-4451b.stat, derby-4451c.diff, derby-4451c.stat
>
>
> I see this error when I specify the columns in a different order than in the 
> table definition. It only fails if a multi-row table constructor is used.
> ij> create table t(a int, b generated always as (-a));
> 0 rows inserted/updated/deleted
> ij> insert into t(b,a) values (default,1);
> 1 row inserted/updated/deleted
> ij> insert into t(b,a) values (default,1), (default, 2);
> ERROR XJ001: Java exception: '1 >= 1: 
> java.lang.ArrayIndexOutOfBoundsException'.
> And in a sane build:
> ij> insert into t(b,a) values (default,1),(default,2);
> ERROR XJ001: Java exception: 'ASSERT FAILED More columns in result column 
> list than in base table: org.apache.derby.shared.common.sanity.AssertFailure'.
> This bug may be similar to DERBY-4448, but the stack trace is different, and 
> DERBY-4448 does not raise an ASSERT FAILED in sane builds.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to