db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-481) implement SQL generated columns
Date Tue, 18 Nov 2008 18:19:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648689#action_12648689

Dag H. Wanvik commented on DERBY-481:

Reviewed derby-481-05-aa-update. Thanks for all this work, Rick! 
Thorough work, I think, and the approach is well integrated with the rest of the
machinery.  Explanations again helped me through this one; some
unclear points ("why is this needed?") from the the preceding "insert" patch became
clear now.

Minor notes:

M      java/engine/org/apache/derby/impl/sql/compile/UpdateNode.java

- import of C_NodeTypes occurs twice now. New imports of
  java.util.ArrayList and java.util.Array is also unneeded.

- comment ca line 578 starting "Get and bind all check constraints.."
  should mention generated columns too.

- addGeneratedColumns's dummy declaration can omitted by using
  getNullNode(gc.getType()) instead.

- At declaration time of bindStatement's addedGeneratedColumns, it
  would be nice to mention what this variable is used for (grant
  "forgiveness" in forbidGenerationOverrides).

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/GeneratedColumnsTest.java

- pedantic note: assertTriggerStatus makes a select which does no
  ORDER BY before comparison with canon; it's OK here of course, since
  it's a VTI for which we have control over the order of the rows
  handed out..

> implement SQL generated columns
> -------------------------------
>                 Key: DERBY-481
>                 URL: https://issues.apache.org/jira/browse/DERBY-481
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-481-00-aa-prototype.diff, derby-481-01-aa-catalog.diff, derby-481-02-aa-utilities.diff,
derby-481-03-aa-grammar.diff, derby-481-04-aa-insert.diff, derby-481-05-aa-update.diff, derby-481-06-aa-genreferences.diff,
derby-481-07-aa-noSQLinRoutines.diff, derby-481-07-ab-noSQLinRoutines.diff, derby-481-08-aa-castToDeclaredType.diff,
derby-481-09-aa-dummyDefaults.diff, derby-481-10-aa-foreignKeyActions.diff, derby-481-11-aa-notNull.diff,
derby-481-12-aa-padding.diff, derby-481-13-aa-alterDatatype.diff, derby-481-14-ab-dropColumn.diff,
derby-481-15-aa-renameAndAddDefault.diff, derby-481-16-aa-dropFunction.diff, derby-481-17-aa-currentSchema.diff,
GeneratedColumns.html, GeneratedColumns.html
> Satheesh has pointed out that generated columns, a SQL 2003 feature, would satisfy the
performance requirements of Expression Indexes (bug 455). Generated columns may not be as
elegant as Expression Indexes, but they are easier to implement. We would allow the following
new kind of column definition in CREATE TABLE and ALTER TABLE statements:
>     columnName GENERATED ALWAYS AS ( expression )
> If expression were an indexableExpression (as defined in bug 455), then we could create
indexes on it. There is no work for the optimizer to do here. The Language merely has to compute
the generated column at INSERT/UPDATE time.

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

View raw message