db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Collation feature discussion
Date Mon, 26 Mar 2007 17:45:03 GMT
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Hi Mamta,
>> Thanks for this extensive write-up. This helps me puzzle through the 
>> issues although I'm afraid I'm still muddled. Some comments follow 
>> inline.
> Same here.
>> Mamta Satoor wrote:
>>> lots of good stuff ...
> +1
>> I think we should avoid violating the SQL standard if we can.
> +1
> In looking at this I was wondering if it would be useful if it could 
> be described in terms of SQL Standard constructs how the system 
> columns come to have a different collation. E.g. is it as though they 
> are declared at the column level with a <collate clause>, or is it as 
> though the system schemas are declared with a different character set 
> to the user schemas?
> Would this make a difference in how a string literal or other 
> character expressions are collated?
> For string literals
> 5.3 SR15) says the collation is the character set collation, and then 
> 5.3 SR14b) says the character set is the the character set of the 
> SQL-client module that contains the <character string literal>.
Here's my interpretation of this. The standard allows you to override 
the default collation bound to a character set. You can override the 
default collation for your whole SQL session or for all of the code in 
a  SQL module. I think that SR14b is trying to describe the behavior 
you'll see if you have explicitly overridden the collation for a 
character set. My hunch would be that this clause does not apply to us 
because we don't allow collations to be overridden at these higher 
levels. For more context, search the spec for feature F693--it's the 
optional feature for allowing these higher level collation overrides.

> So here's it's unclear to me what 'SQL-client module' means in a derby 
> context.
> For a function (or any other declared character type except column 
> definitions) the collation will come from its data type, which goes to 
> 6.1 SR3b) and 6.1 SR16), which says implementation defined character set.
> For a column definition then 11.4 SR10b) specifies the character set 
> as being the schema's character set.
> Thus Derby could have two character sets:
>   - USER - UCS repertoire with default collation of UCS_BASIC or 
> UNICODE depending on value of collation JDBC attribute at create 
> database time
>  - SYSTEM - UCS repertoire with default collation of UCS_BASIC
> When a schema is created it is implementation defined as to its 
> character set (if one is not defined) 11.1 SR5)
> So Derby's implementation could be:
> user schemas have a character set of USER
> system schemas have a character set of SYSTEM
> Then ...
>   - columns would have the required collation (11.4 SR10b))
>   - functions (& others) would have the required collation (Derby's 
> implementation could be to pick the schema character set)
> which leaves string literals as the issue, what is a 'SQL-client module'?
> Dan.

View raw message