Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <465E5299.3060604@apache.org>
Date: Wed, 30 May 2007 21:44:09 -0700
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: more on system schema vs. user schema and character constants.
References: <465E1595.6030800@sbcglobal.net>
In-Reply-To: <465E1595.6030800@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mike Matrigali wrote:
> I am sort of confused at this point, what we expect to be working
> now and what should be.  What is the right way to write the
> following query against a the system schema?  Is there anyway to
> write the query without changing the default schema? :

Not sure if it's related or not but I just noticed this code in CastNode 
and there is other similar fragments elsewhere in ValueNodes.

     //set the collation type to be same as the current schema's
     //collation type. Collation derivation is already initialized
     //to correct value by default which is "IMPLICIT"
     getTypeServices().setCollationType(
   getLanguageConnectionContext().getDefaultSchema().getCollationType());

I think this is incorrect. During compilation the correct value to get 
the current schema is using the getSchemaDescriptor(null) call for any 
node. The current schema for compilation will not match the connection's 
current schema in some situations, such as compiling an action statement 
for a trigger, a sps for metadata queries and possibly for views as well.

If this code is frequent it might be worth creating a utility method in 
ValueNode as

  setSchemaCollation() {
     getTypeServices().setCollationType(
      getSchemaDescriptor(null).getCollationType());
  }

Dan.