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 03:31:44 GMT

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

Dag H. Wanvik commented on DERBY-481:
-------------------------------------

Reviewed derby-481-04-aa-insert.  Quite a mouthful, this one :) Looks
good, though. Thanks for the detailed explanation of the code; very
helpful.  I wasn't able to locate the "similar poking" being done for
the CHECK codepaths; could you point me to that?

Minor notes:

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

- I think createGeneratedColumn can be simplified by using arg
  getNullNode(colDesc.getType()) instead of the dummy declaration?

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

- javadocs for forbidGenerationOverrides, parseAndBindGenerationClauses
  and generateGenerationClauses lack @params

- The "continue" statement after hasGenerationClauses has been
  established as true can be replaced by a break; no need to see more.
  The initial comment in this loop ("generate statements of the
  form..")  seem misplaced too, since this loop is only used to detect
  is there exists a generation clause. It should probably be moved to
  after the loop?

- I see you have just followed the pattern from check constraints, but
  I am not sure I like the fact that there are two overloaded public
  methods called generateGenerationClauses which seem to be on
  different levels of abstraction. The innermost can be private,
  btw. I would have preferred different names for them.

M      java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
- has lots of spurious diffs; only one significant change.

M      java/engine/org/apache/derby/impl/sql/execute/NoRowsResultSetImpl.java

- The method evaluateGenerationClauses could be made protected and
  moved down to DMLWriteResultSet. It lacks @params for its javadoc.


> 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: 10.0.2.1
>            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.


Mime
View raw message