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

Kathey Marsden commented on DERBY-118:
--------------------------------------

+1 to a separate issue for moving the length default checks to DDL time.

Am I correct that the current patch is limited in scope to allowing defaults 
greater than 254 for varchar columns?   If so,  I think it might be good to 
make a separate issue or subtask with  the specific description of the change. 
This I think makes release notes a lot clearer. 

Also it seems that we have migrated away from the original request. Allow Any 
built-in function as a default value. As I understand it we decided that was 
non-standard.   Perhaps it would make sense to open even another subtask  or 
linked issue for that and close it won't fix because it is not standard and 
refer to the discussion in this issue issue.

I think general tracking issues for things like lifting defaults, new JDBC 
versions, etc are great, but think it is best to have specific functionality 
tracked as separate linked issues or subtasks with clear descriptions and have 
the checkins occur under those issues.  It makes the release notes much clearer 
and historical eploration much easier.
 

                
> Lift some DB2 restrictions on DEFAULT values [was: Allow any build-in 
> function as default values in table create for columns]
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-118
>                 URL: https://issues.apache.org/jira/browse/DERBY-118
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Bernd Ruehlicke
>            Assignee: Dag H. Wanvik
>            Priority: Minor
>         Attachments: derby-118-all-defaults.diff, 
> derby-118-limited-even-more-b.diff, derby-118-limited-even-more-b.status, 
> derby-118-limited-even-more.diff, derby-118-limited-even-more.status, 
> derby-118-limited.diff, derby-118-limited.status, derby-118-longvarchar.diff, 
> derby-118.diff, derby-118.stat, derby-118b.diff, derby-118b.stat, 
> derby-118c.diff, derby-118c.stat
>
>
> It is ok in ij to do a   values char(current_date)   but is is not allowed to 
> use char(current_date) as default value for clolumns; like for example
> CREATE TABLE DOSENOTWORK (num int, created_by varchar(40) default user, 
> create_date_string varchar(40) default char(current_date))
> Request: It should be allowed to use any build-in function which return a 
> valid type as part of the default value spec.
> There was a e-mail thread for this and the core content/answer was:
> Bernd Ruehlicke wrote:
> > 
> > CREATE TABLE DOSENOTWORK (num int, created_by varchar(40) default 
> > user, create_date_string varchar(40) default char(current_date))
> > 
> > give an error as below - any idea why ?!??!
> > 
> The rules for what is acceptable as a column default in Derby say that the 
> only valid functions are datetime functions. 
>   The logic that enforces this can be seen in the "defaultTypeIsValid" method 
> of the file:
> ./java/engine/org/apache/derby/impl/sql/compile/ColumnDefinitionNode.java
> The Derby Reference Manual also states this same restriction (albeit rather 
> briefly):
> ----
> Column Default
> For the definition of a default value, a ConstantExpression is an expression 
> that does not refer to any table. It can include constants, date-time special 
> registers, current schemas, users, and null.
> ----
> A "date-time special register" here means a date-time function such as 
> "date(current_date)" in your first example. 
> Since the function "char" is NOT a date-time function, it will throw an error.
> I believe this restriction was put in place as part of the "DB2 
> compatibility" work was that done in Cloudscape a while back.
> Hope that answers your question,
> Army

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to