>> Can someone please explain the design goal behind the whole trimming
>> of CHAR columns, please? I remember that in the past CHAR columns
>> were handled more efficiently by DBMSs than VARCHAR but I remember
>> having read in the Oracle docs that this is no longer true.
>
> That's what I heard in the past too. Not sure what is the current
> situation. In any event I suspect it to be database-dependent.
Right. MySQL does not pad CHAR columns, Holger reported this some time
ago IIRC.
> Also since there is a CHAR type in JDBC, we must support it correctly.
> It is up to the users to avoid using it in the design.
Ok. When I initially found out about the behaviour of
QualifierTranslator, I wasn't too exited about the behaviour. Now, that
I have thought a bit more about it, I like it better and better. One
thing I'd like to experiment with a bit more is the performance of
RTRIM() queries against normal queries.
> I guess for now we may need a PostgresQualifierTranslator, just like
> Oracle's. Later we may refactor it into an adapter-independent
> subclass of QualifierTranslator.
Just for testing I added an OracleQualifierTranslator (since Postgres
has RTRIM, too) to the PostgresAdaptor and re-ran the SelectQueryTst.
It's all green now :-) So I guess refactoring OracleQualifierTranslator
to a CharColumnTrimQualifierTranslator would be the next logical step.
-dirk
This archive was generated by hypermail 2.0.0 : Tue Feb 18 2003 - 14:55:29 EST