> The difference between CHAR and VARCHAR is that VARCHAR saves only the
> significant characters and trailing blanks are considered
> insignificant. Even using
> CHAR, you'll find that 'ABC ' is the same as 'ABC' - the SQL
> standard specifies
> that when comparing CHAR or VARCHAR values the shorter value will be
> extended
> with blanks to the length of the longer.
>
> If you want blanks saved consistently, use CHAR. It won't make any
> difference
> on disk because run-length compression will eliminate the blanks, but for
> your application and for transferring data, using CHAR will appear to
> preserve
> trailing spaces.

Am I reading you right that you say that trailing spaces would be stripped from VARCHAR values as they would not be significant? As far as I can see the SQL standards (and Firebird itself) disagree with that (for example SQL92, section 9.1 and 9.2).

For a target-type of CHAR both store and retrieval will right pad with spaces (as you say). However for a target-type of VARCHAR both store and retrieval should preserve the exact string supplied including trailing spaces(!) as long as the length of the string does not exceed the length of the target. That means that any trailing spaces explicitly supplied will not be stripped from a VARCHAR value.
So if I insert a String 'A ' in VARCHAR of length 5 or larger, I should get that exact same string back when queried it should not trim the spaces. Firebird BTW does exactly that.

I would sooner say that if you want to save trailing spaces consistently (as in: what goes in comes out again), then you use VARCHAR, if you want everything to have the same length (padded with spaces), then you use CHAR.

I do agree with you that trailing spaces are considered insignificant in comparisons (SQL92 section 8.2).

Mark
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de