db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6340) Add support for CREATE TYPE AS <existing type> (synonym types)
Date Tue, 08 Oct 2013 12:30:43 GMT

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

Knut Anders Hatlen commented on DERBY-6340:

DERBY-5901 might not be an issue for the implicitly created functions after all. The built-in
conversion functions (INT, CHAR, DOUBLE, ...) have special handling in the parser, so they
don't behave like the SIN function that's used in the example in DERBY-5901.

Since the names of the built-in types are reserved keywords, user-defined functions with the
same name as a built-in type need to be quoted in order to get CREATE FUNCTION to accept them.
Conversely, when invoking a function with the same name as a built-in type, the parser always
knows whether to use the built-in one (if the function name is a keyword) or look for a user-defined
one (if the function name is an identifier).

That is, {{VALUES INT(1)}} will always invoke the built-in function, regardless of the existence
of a user-defined function with the same name in the current schema. And {{VALUES "INT"(1)}}
will never invoke the built-in function, as the function is referenced with an identifier
rather than a keyword, regardless of the existence of a user-defined function with that name.

So given the statement


a new function called "INT" will be created in the current schema. But its existence will
not affect any existing callers of the INT built-in conversion function, I believe.

That doesn't help with the other issue, though. If you create a second type that also maps
to INT, such as {{CREATE SHOE_SIZE AS INT}}, it will attempt to create yet another "INT" function,
and Derby doesn't support that kind of overloading yet.

In short, I think that means we could allow CREATE TYPE AS statements without <cast to
source> without worrying about DERBY-5901. But if we create a second type in the same schema
with the same source type, that second CREATE TYPE AS statement must include <cast to source>
and specify a non-conflicting name as long as function overloading isn't implemented.

> 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

This message was sent by Atlassian JIRA

View raw message