Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <800946226.1204907746513.JavaMail.jira@brutus>
Date: Fri, 7 Mar 2008 08:35:46 -0800 (PST)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3512) Using functions, you can create a LONG
 VARCHAR value which is longer than the maximum length of a Derby LONG
 VARCHAR
In-Reply-To: <99824630.1204907746485.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-3512:
---------------------------------

    Attachment: bigStrings.sql
                BigStringMaker.java

To demonstrate the problem, do the following:

1) Compile BigStringMaker

2) Run bigStrings.sql through ij.

> Using functions, you can create a LONG VARCHAR value which is longer than the maximum length of a Derby LONG VARCHAR
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3512
>                 URL: https://issues.apache.org/jira/browse/DERBY-3512
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.4.0.0
>            Reporter: Rick Hillegas
>         Attachments: BigStringMaker.java, bigStrings.sql
>
>
> I can create a static method which returns a long String and register this as a function which returns LONG VARCHAR. I am able to invoke this function and create a LONG VARCHAR value which is longer than the maximum length which Derby allows for this datatype (32700 characters).
> It is not clear to me what is supposed to happen in this situation according to the SQL standard. However, the current behavior seems wrong. Here are two possible correct behaviors:
> 1) Raise an exception if the user-coded method violates the declared contract of the CREATE FUNCTION statement.
> 2) Silently truncate the value returned by the user-coded method.
> There may be a similar problem with methods which return byte[] and which are registered as functions returning (LONG) VARCHAR FOR BIT DATA. However, experiments to test this are blocked by DERBY-3511.
> I will attach a test case demonstrating the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.