Subject | Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR? |
---|---|
Author | Mark Rotteveel |
Post date | 2019-11-14T13:27:56Z |
On 2019-11-13 18:42, blackfalconsoftware@... [firebird-support]
wrote:
character sets, 0x00 for octets), while a VARCHAR will be stored 0x00
padded. However, due to a RLE (Run Lenght Encoding) applied, that padded
will be stored 'compressed'.
maximum of n characters, the only difference is that the value (as seen
by the consumer) of a CHAR(n) is right-padded with spaces, while a
VARCHAR(n) is not padded.
Mark
wrote:
> Here is the link to the definition of CHAR and VARCHAR fieldThat is incorrect. A CHAR will be stored blank-padded (space for normal
> definitions from the IB-Experts site...
>
>
> https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR
> https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR
> In neither the CHAR or VARCHAR definitions is it noted that unused
> space is filled with nulls or blank data as both are stored as
> variable length fields internally within a table.
character sets, 0x00 for octets), while a VARCHAR will be stored 0x00
padded. However, due to a RLE (Run Lenght Encoding) applied, that padded
will be stored 'compressed'.
> However, the CHARThat is incorrect. Both a VARCHAR(n) and a CHAR(n) will allow storing a
> data type, as would be expected, can only store as a maximum, the
> number of characters that its original definition set forth. The
> VARCHAR field can hold up to over 32,000+ bytes of data.
maximum of n characters, the only difference is that the value (as seen
by the consumer) of a CHAR(n) is right-padded with spaces, while a
VARCHAR(n) is not padded.
Mark