On 2019-11-14 03:40, Richard Damon [email protected] [firebird-support] wrote: > On 11/13/19 9:51 AM, [email protected] [firebird-support] > wrote: >> >> Thank you Anne, for your succinct comments regarding the differences >> between the efficiencies of a CHAR and VARCHAR field definitions. >> >> Human observation cannot actually elicit any observable effects >> between the two. >> >> However, internally, the CHAR field definition is more efficient as >> the database does not have to perform any field size calculations at >> the moment that data is being updated to a VARCHAR field. Again, this >> is not noticeable to a user unless the data that is being updated into >> a VARCHAR field is quite large. >> >> Steve Naidamast >> Sr. Software Engineer > > By the SQL standard, there are some noticeable effects. CHAR is defined > as a fixed width, so data is padded with blanks to reach that width, > and > then the blanks are removed on retrieval. Because of this, a CHAR field > can not store a value with trailing blanks. On the other hand, since > VARCHAR doesn't need to pad the field, it doesn't need to trim trailing > blanks, so the field CAN store data with trailing blanks.
CHAR values in the SQL standard retain the padding: it is not removed on retrieval. Mark
