On 2019-11-14 03:40, Richard Damon richard@...
[firebird-support] wrote:

> On 11/13/19 9:51 AM, blackfalconsoftware@... [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