[
https://issues.apache.org/jira/browse/DERBY-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788111#comment-13788111
]
Rick Hillegas commented on DERBY-6340:
--------------------------------------
Hi Dyre,
Thanks for continuing to button-down this spec. Some responses follow:
> Is DERBY-5901 the reason why the name must not conflict with a builtin
> function or aggregate?
Yes, that's right.
> Without the ability to specify <cast to source> you can create at
> most one alias for each builtin type in the same schema?
That's not my reading. The Standard lets you create multiple routines with the
same schema-qualified name provided that their argument signatures are
different. Derby does not support this flexibility with user-created routines,
but that's a limitation we could lift with a little work. For the SQL Standard
rules, see part 2, section 4.28; in the 2011 edition, the relevant paragraph is
the last paragraph on page 98.
> Due to DERBY-5901, we must either always specify
> <cast to source> or let the default identifier be non-standard as
> the default names mandated by the standard are already
> used by existing builtin functions in Derby?
Again, that's not my reading. I don't think that we need the <cast to source>
clause. The different distinct types will implicitly create <cast to source>
functions which have the same name but different argument signatures.
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_2.html, 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 was sent by Atlassian JIRA
(v6.1#6144)
