[
https://issues.apache.org/jira/browse/DERBY-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779149#comment-13779149
]
Rick Hillegas commented on DERBY-6340:
--------------------------------------
Thanks for the first rev of this functional spec, Dyre. A couple comments
follow:
o In several places you say that Derby's existing CREATE TYPE language is
non-standard. It seems to me that it conforms to part 13 of the SQL Standard
(SQL/JRT), section 9.4 (user defined type). Can you help me understand why you
think that the existing Derby CREATE TYPE language falls outside the standard?
o Under "New Keywords" you say that this spec introduces no new keywords.
However, right now it does introduce the FINAL keyword, which is listed as a
non-reserved keyword in the 2011 version of the Standard, part 2, section 5.2
(token and separator). FINAL does not appear in Derby's reserved or
non-reserved keyword lists right now. It seems to me that the spec could
finesse this issue by not introducing FINAL at all. The spec only allows for
FINAL types and that is the default finality of a user-defined type. The FINAL
keyword can therefore be omitted.
o Under "New CREATE TYPE Statement Syntax" you present a grammar with many
sections in light-gray. Does light gray mean that those parts of the grammar
will not be implemented?
o It would be good if that section also clarified that you can't specify any of
the user-defined type options more than once.
o It would be good if the spec described the effect of the cast-to-distinct and
cast-to-source clauses. It is my understanding that they declare names for
functions which cast between the distinct type and its underlying predefined
type. It would be good to see a description of the comparison and casting
behavior of distinct types and how these functions would be used.
o But much of the preceding comments may be moot if you take the following
advice. It's your judgment call, but I think that most of the value of this
language is supplied by the following simplified syntax. This would reduce the
size of this feature. That is, you could omit the implicit FINAL clause (which
is a NOP) and the casting clauses (which I don't think will be used widely):
CREATE TYPE [ schemaName. ] typeName AS builtinType
o There's a little more to say about DatabaseMetaData, so I recommend moving
that material out of the "Public API" section into a section devoted to
DatabaseMetaData. In particular, DatabaseMetaData.getTypeInfo() will need to
return an additional row stating that Derby supports DISTINCT types (see the
javadoc for that method).
o Under "System Tables": I think that you should be able to hide all of the
details of the distinct type inside the Formatable AliasInfo object stored in
SYS.SYSALIASES.ALIASINFO. You may find it is convenient to declare a new
NAMESPACE constant, but I'm cautiously hopeful that won't be necessary. Due to
the way the code is structured, introducing a new NAMESPACE constant will
introduce more cases in the switch statements which already handle the alias
descriptors.
o Because you will have to extend UDTAliasInfo or introduce a new
DistinctAliasInfo class, there will be changes to the system catalogs. So this
feature can only be enabled after hard-upgrade.
o However, I don't see any backward compatibility issues.
o Under "Documentation", you will want to note that changes will need to be
made to the Reference Manual sections on the CAST operator and on "Data type
assignments and comparison, sorting, and ordering".
Thanks!
-Rick
> Add support for CREATE TYPE AS <existing type> (synonym types)
> --------------------------------------------------------------
>
> Key: DERBY-6340
> URL: https://issues.apache.org/jira/browse/DERBY-6340
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
> Attachments: CreateTypeAs_fs_draft.html
>
>
> The SQL standard (2003) chapter 11.41 <user-defined type definition> allows
> the creation of synonyms or aliases for an existing type: CREATE TYPE AS
> <predefined type>. By allowing this in Derby we would simplify migration
> from, and interoperation with, other databases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
