You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2014/07/01 10:28:25 UTC

[jira] [Commented] (DERBY-6609) Documentation for SQL features should reflect current standard

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

Knut Anders Hatlen commented on DERBY-6609:
-------------------------------------------

Hi Kim,

I'm done researching, so I think it's safe to start on a patch based on the latest information. I might have missed some features or misinterpreted some, but we can treat those as bugs later if someone finds that something is wrong.

F382: Good catch! Yes, would be good to have that fixed. VARCHAR, VARCHAR FOR BIT DATA, CLOB and BLOB all work:

{noformat}
ij> create table t(vc varchar(10), vcb varchar(10) for bit data, c clob(10), b blob(10));
0 rows inserted/updated/deleted
ij> alter table t alter column vc set data type varchar(100);
0 rows inserted/updated/deleted
ij> alter table t alter column vcb set data type varchar(100) for bit data;
0 rows inserted/updated/deleted
ij> alter table t alter column c set data type clob(100);
0 rows inserted/updated/deleted
ij> alter table t alter column b set data type blob(100);
0 rows inserted/updated/deleted
{noformat}

Actually, the syntax for VARCHAR FOR BIT DATA looks wrong in the reference manual. The length argument is on the wrong spot. It should be {{columnName SET DATA TYPE VARCHAR ( integer ) FOR BIT DATA |}} rather than {{columnName SET DATA TYPE VARCHAR FOR BIT DATA( integer ) |}}.

F690: Yes, that looks correct on trunk.

> Documentation for SQL features should reflect current standard
> --------------------------------------------------------------
>
>                 Key: DERBY-6609
>                 URL: https://issues.apache.org/jira/browse/DERBY-6609
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.11.0.0
>            Reporter: Kim Haase
>            Assignee: Kim Haase
>         Attachments: DERBY-6609-2.diff, DERBY-6609-2.zip, DERBY-6609-3.diff, DERBY-6609-3.diff, DERBY-6609-3.stat, DERBY-6609-3.zip, DERBY-6609-3.zip, DERBY-6609-4.diff, DERBY-6609-4.stat, DERBY-6609-4.zip, DERBY-6609-5.diff, DERBY-6609-5.stat, DERBY-6609-5.zip, DERBY-6609.diff, DERBY-6609.stat, DERBY-6609.zip
>
>
> We document Derby as an SQL-92 database. This standard is now very old, and we should describe how Derby conforms to the most current standard (SQL:2011). Knut Anders Hatlen listed the relevant features in a comment to DERBY-6605. 
> This will involve at a minimum replacing the "Derby support for SQL-92 features" topic (http://db.apache.org/derby/docs/10.10/ref/rrefsql9241891.html) with a new one that describes Derby's support for current features, with notes as needed indicating when the support is partial. Only features Derby supports, fully or partially, should be listed. We should state that features not listed are not supported.
> The information would be taken from http://wiki.apache.org/db-derby/SQLvsDerbyFeatures (which currently goes only through the 2003 standard). Listing the Feature IDs in the documentation would also be helpful. 
> Other topics should be changed as needed. For example, is the term "SQL92Identifier" still correct?



--
This message was sent by Atlassian JIRA
(v6.2#6252)