Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <29611788.1180735397561.JavaMail.jira@brutus>
Date: Fri, 1 Jun 2007 15:03:17 -0700 (PDT)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2731) String literal constants currently
 take the collation of the compilation schema but the wiki page
 http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478
 expects USER schema collation.
In-Reply-To: <19669166.1180551135840.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-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500871 ] 

Daniel John Debrunner commented on DERBY-2731:
----------------------------------------------

Looking at other databases I see

Microsoft SQL Server - string literals take on default collation of database
MySQL - string literals take on default collation of connection
Postgres - only supports single collation per database (????)

Any others? Oracle? (I couldn't find mention of collation in Oracle 10g's character set section)

One issue with the per schema approach is statement caching. Currently statement caching at a per-schema approach so there's no problem.
However for statements that don't depend on the current schema it would be good to cache them across schemas, e.g.
 
       SELECT * FROM A.T

Especially when the default schema for a user is specific to that user.
With string literals taking information from the current schema, now a statement like:

     SELECT * FROM A.T WHERE TYPE = 'CAR'

will be dependent on the current schema, thus not shareable (due to the collation for 'CAR' requring a lookup of the current schema)

In fact thinking about it, it does look strange that such a statement is dependent on the collation of the current schema, I'm not sure that's what an application developer will be expecting when they write a statement like that (principle of least surprise).

I'm not sure what's right here, just trying to expand the discussion so all angles have been looked at.

In some ways it would seem useful in TYPE = 'CAR' for 'CAR' to take on the collation of TYPE, but it's clear in the SQL standard that both have implict collation derivation (even though we can't work out what the collationtype  of 'CAR' is defined to be).

> String literal constants currently take the collation of the compilation schema but the wiki page http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478 expects USER schema collation.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2731
>                 URL: https://issues.apache.org/jira/browse/DERBY-2731
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mamta A. Satoor
>            Assignee: Mamta A. Satoor
>
> I checked in code some time back which sets the collation type of string literal to be same as the compilation schema. The advantage of this is that metadata queries will work without changes since those queries do character string literal comparisons.
> But the wiki page at http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478 in Section Collation Determination, Rule 1) says that character string literal should always take the collation of user schema. This decision was based on the discussion in the Collation feature discussion thread at http://www.nabble.com/Collation-feature-discussion-tf3418026.html#a9675967. SQL spec defines the behavior here to be implementation defined (it says that in a convoluted way which can be found in the Collation feature discussion). But considering the impact it will have on the metadata queries (they will have to be changed so that we CAST character string literals so that they will take the collation of system schema and hence the comparison will not fail), should we reconsider our decision made on the wiki page. 

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