db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-118) Lift some DB2 restrictions on DEFAULT values [was: Allow any build-in function as default values in table create for columns]
Date Wed, 20 Jun 2012 01:06:42 GMT

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

Mamta A. Satoor commented on DERBY-118:
---------------------------------------

Hi Dag, I looked at the SQL spec(The SQL standard 2003, Part 2: Foundation (SQL/Foundation))
pg 539 talks about <default clause> and it says following at the end of the page 4)a)i)
If the subject data type is character string, then the <literal> shall be a <character
string literal>.
If the length of the subject data type is fixed, then the length in characters of the <character
string literal> shall not be greater than the length of the subject data type. If the length
of the
subject data type is variable, then the length in characters of the <character string literal>
shall
not be greater than the maximum length of the subject data type. The <literal> shall
have the
same character repertoire as the subject data type.

Based on this, I think we should only implement the a) part of the patch but not b), ie we
should move the check back to "create table" time.
a)The DEFAULT for varchar will not be limited to 254 characters and it will accept a string
as big as the length of the varchar 
b)If the DEFAULT value for a char datatype is larger than it's size, it will not be caught
at the CREATE TABLE time. 
                
> 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.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

        

Mime
View raw message