Re: Binding on a char column

Oh, yes, now I understand better! Thanks!

What I meant with my last message, was that I'd like not to use RTRIM. And I was asking if oracle gives to user the possibility not to use RTRIM specifying an option in oracle environment. I don't know if it's clear my question.

I understand about indexes, char vs. varchar, but for me these are big changes to introduce to my database.
Till now we didn't use bind variables and we could execute an sql queries such:
select * from table where column = 'test' also if column is char(10). Now with bind variables 'test' is binded.

I was searching a non expensive way to implement it. Indexes or migrate to varchar are just a little problematic fo me. If oracle manages this behaviour (char column with bind variable) could be very useful for me! I don't know if you could understand me!

Thank you very much for you attention!

hpuxrac ha scritto:

> silvia.fama wrote:
> > Thank you very much!
> > I believe that the best is to use varchar instead of char.
> >
> > I hoped oracle may give me the possibility to set an option or
> > parameter that allows me not to use RTRIM with bind variables. I
> > suppose it doesn't exist, and your very useful suggestion are the only
> > way to resolve this problem!
> > May you confirm it?
> >
> > Thank you and kind regards!
>
> You lost me a little on your question above Silvia.
>
> Oracle has to look at the SQL that you send in and the where clause.
> When the cost based optimizer see's a function ( like RTRIM ) on the
> left hand side ( RTRIM(some_column = 'value' or :bind_variable ) it
> checks indexes that it has against the column.
>
> If there is only a "regular" index on the some_column and not an index
> ( RTRIM(some_column ) )that includes the function ( and matches the
> WHERE clause construct ) the optimizer usually decides that it can't or
> won't try to use than index.
>
> Have you looked at the Tom Kyte site http://asktom.oracle.com ... try
> doing some searches on "char" and "varchar" ... lots of good
> information there.
Received on Wed Jan 17 2007 - 08:43:00 CST