Re: Should we have dynamic like optimization with TERRITORY_BASED collation

[Kathey Marsden]

Mamta Satoor wrote:

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

Sounds intentional. Thanks Mamta

On 7/23/07, *Kathey Marsden* <[EMAIL PROTECTED] <mailto:[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 >=, < 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();
       }