[
https://issues.apache.org/jira/browse/DERBY-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652147#action_12652147
]
Rick Hillegas commented on DERBY-481:
-------------------------------------
Hi Dag,
Thanks for your second batch of comments on November 26. I agree that it seems
silly for RESTRICT to prevent you from dropping a column which is constrained
by a CHECK constraint that only mentions that column. I'm not sure that the
language of section 11.18 addresses this silliness, though. In the example from
our test code, the CHECK constraint seems to me to be a column level CHECK
constraint, not a table level constraint--so the exception in syntax rule (5b)
doesn't apply. This is puzzling though. I don't know why the CHECK constraint
would block a RESTRICTed DROP when phrased at the column level but would not
block the DROP when phrased at the table level.
> 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,
> derby-481-18-aa-updatableResultSets.diff, derby-481-19-aa-cleanup.diff,
> derby-481-20-aa-cleanup.diff, GeneratedColumns.html, 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.
