Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 64705 invoked from network); 4 Apr 2007 20:47:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Apr 2007 20:47:19 -0000 Received: (qmail 41766 invoked by uid 500); 4 Apr 2007 20:47:25 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 41741 invoked by uid 500); 4 Apr 2007 20:47:25 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 41732 invoked by uid 99); 4 Apr 2007 20:47:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Apr 2007 13:47:25 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of msatoor@gmail.com designates 209.85.132.246 as permitted sender) Received: from [209.85.132.246] (HELO an-out-0708.google.com) (209.85.132.246) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Apr 2007 13:47:17 -0700 Received: by an-out-0708.google.com with SMTP id c25so401788ana for ; Wed, 04 Apr 2007 13:46:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Q8UuprHpV/x7Sdr0/oAGt4PjBntLDpBkAD63q92wcoyWtPxSKMi9ZtEWr6I9a5Q+c5OJFvN/YSOoXS9DfH2+N19SMwUvl4ts51vuGJiUXCMzY8ixbi8uQMr1s0PGAELTW0t1prD2Iw1cTSbebdaPUK4tMlnqiyxuzh8iuVGjT1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XQwcCohsJ4c+LprGBJ1uJyam1CYx4n0L67TpdzpyU903Hixt6tk9bwLJnZ5kzMgfxy6Nl9ABPR5qS0BCRK9Ji/wUkMOhssDrCx4HnL5CsA1etnuPEixxOKNsLpc+Ui0VXaxYnQeTOkHn9XDhX7bh2JgR3xaXhA7qWx8xn0Yjra0= Received: by 10.100.43.9 with SMTP id q9mr786124anq.1175719615285; Wed, 04 Apr 2007 13:46:55 -0700 (PDT) Received: by 10.100.136.4 with HTTP; Wed, 4 Apr 2007 13:46:55 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 13:46:55 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: DERBY-1478 : Making the correct collation type available in CreateTableNode for character string type columns In-Reply-To: <46140C70.5080104@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38556_7913494.1175719615034" References: <4613F9CD.3050508@apache.org> <46140C70.5080104@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_38556_7913494.1175719615034 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline OK. I am also wondering about the 2 character sets that Derby 10.3 would have. All the user schemas as per the wiki page would have USER character set and the system schemas will have SQL_IDENTIFIER character associated with them. I am wondering if we leave these at conceptual level and just have the collation type correctly set on the SchemaDescriptor? ie no code corresponding to character set in SchemaDescriptor? Mamta On 4/4/07, Daniel John Debrunner wrote: > > Mamta Satoor wrote: > > Yes, I thought of going that track, but that would involve saving the > > collation type in SYSCHEMAS and thus some hard upgrade code. In soft > > upgrade, we can't upgrade SYSCHEMAS, so some mechanism to have it > > default to UCS_BASIC. > > No, no need to save anything in SYSSCHEMAs. The data dictionary could > set the schema's default collation default type when loading. > SchemaDescriptor has a isSystemSchema() method so it's clear which are > system schemas and which are not. > > > Dan. > > > > > > > > The collation you are looking for is a property of the schema, see > this > > from your 1478 wiki page: > > > > > 2) (of character string type) SQL spec Section > > 11.1 , General Rule 3 specifies that the > > character set associated with schema is used as the default > > character set for all . > > > > Thus, since it's a property of the schema, the most logical place > for > > this is as a method on SchemaDescriptor, > > e.g. > > > > public int getCollationType(); > > > > > > Dan. > > > > > > > > > ------=_Part_38556_7913494.1175719615034 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
OK. I am also wondering about the 2 character sets that Derby 10.3 would have. All the user schemas as per the wiki page would have USER character set and the system schemas will have SQL_IDENTIFIER character associated with them. I am wondering if we leave these at conceptual level and just have the collation type correctly set on the SchemaDescriptor? ie no code corresponding to character set in SchemaDescriptor?
 
Mamta

 
On 4/4/07, Daniel John Debrunner <djd@apache.org> wrote:
Mamta Satoor wrote:
> Yes, I thought of going that track, but that would involve saving the
> collation type in SYSCHEMAS and thus some hard upgrade code. In soft
> upgrade, we can't upgrade SYSCHEMAS, so some mechanism to have it
> default to UCS_BASIC.

No, no need to save anything in SYSSCHEMAs. The data dictionary could
set the schema's default collation default type when loading.
SchemaDescriptor has a isSystemSchema() method so it's clear which are
system schemas and which are not.


Dan.

>

>
>     The collation you are looking for is a property of the schema, see this
>     from your 1478 wiki page:
>
>      > 2)<column definition> (of character string type) SQL spec Section
>     11.1 <schema definition>, General Rule 3 specifies that the
>     character set associated with schema is used as the default
>     character set for all <column definitions>.
>
>     Thus, since it's a property of the schema, the most logical place for
>     this is as a method on SchemaDescriptor,
>     e.g.
>
>     public int getCollationType();
>
>
>     Dan.
>
>
>



------=_Part_38556_7913494.1175719615034--