db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5525) Precision for UPPER function is wrong if the returned value is longer than the literal argument
Date Fri, 09 Dec 2011 14:24:39 GMT

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

Rick Hillegas commented on DERBY-5525:
--------------------------------------

Thanks for digging into the SQL Standard, Dag and Knut. I agree with your reading:

1) Derby is assigning the correct type to upper( expr ) and lower( expr ), viz., the type
of expr.

2) Truncation caused by upper() and lower() should raise a warning.

I can see some value in adding a truncation warning for the case where upper() has to be evaluated
at execution-time:

  select upper( col1 ) from ...

I don't see much value in adding a truncation warning for the case where upper() can be evaluated
at compilation-time:

  select ... where col1 = upper( 'Straße' )

The behavior of ucase() and lcase() fall outside the SQL Standard. However, I don't see any
value in changing these operators to make them behave like SQL functions.

I agree with Knut's interpretation of getPrecision(). For character-typed columns, getPrecision()
is identical to getColumnDisplaySize(), i.e., it is the maximum length of the column's data
type. The ResultSet is evaluated lazily but the immutable ResultSetMetaData is available before
next() is called.

Thanks,
-Rick
                
> Precision for UPPER function is wrong if the returned value is longer than the literal
argument
> -----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5525
>                 URL: https://issues.apache.org/jira/browse/DERBY-5525
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.8.2.2
>            Reporter: Knut Anders Hatlen
>
> Seen in ij in a database with territory based collation and German locale:
> ==vv= COPIED FROM IJ CONSOLE =vv==
> ij> VALUES UCASE('Straßenbahn');
> 1
> -----------
> STRASSENBA&
> 1 Zeile ausgewählt
> ==================================
> And with JDBC calls:
>     Connection c = DriverManager.getConnection(
>             "jdbc:derby:memory:db;create=true;territory=de_DE;" +
>             "collation=TERRITORY_BASED");
>     Statement s = c.createStatement();
>     ResultSet rs = s.executeQuery("values upper('Straße')");
>     System.out.println(rs.getMetaData().getPrecision(1));
>     rs.next();
>     System.out.println(rs.getString(1));
> This prints
> 6
> STRASSE
> The precision is wrong, since the returned value is 7 characters long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message