Kathey, this is another behavior we picked up from national character
types.  LikeEscapeOperatorNode has following comment
       /* If we are comparing a char with a national char then
        * we generate a cast above the receiver to force preprocess to
        * not attempt any of the > <= optimizations since there is no
        * way to determine the 'next' character for the <= operand.

Mamta


On 7/23/07, Kathey Marsden <[EMAIL PROTECTED]> wrote:

The test below fails in DynamicLikeOptimizationTest.    I wonder is this
optimization expected for
TERRITORY_BASED collation or is ok that it is not done.

Kathey


  /**
    * Test that dynamic like optimization is performed. That is, the LIKE
    * predicate is rewritten to &gt;=, &lt; and LIKE.
    */
   public void testDynamicLikeOptimization() throws SQLException {
       Statement s = createStatement();
       s.execute("CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1)");
       PreparedStatement ps =
           prepareStatement("select id from test where vc10 like ?");
       ps.setString(1, "%");
       JDBC.assertDrainResults(ps.executeQuery());
       RuntimeStatisticsParser p =
SQLUtilities.getRuntimeStatisticsParser(s);
       *assertTrue(p.hasGreaterThanOrEqualQualifier());*   <-- FAILS HERE
       assertTrue(p.hasLessThanQualifier());
       s.close();
       ps.close();
   }




Reply via email to