> >>The manual <http://www.mysql.com/doc/en/Open_bugs.html> says
> >>>The following problems are known and will be fixed in due time:
> >>>All string columns, except BLOB and TEXT columns, automatically have
> >>>all trailing spaces removed when retrieved. For CHAR types this is
> >>>and may be regarded as a feature according to SQL-92. The bug is that
> >>>MySQL Server, VARCHAR columns are treated the same way.
> >>That seems the reverse of what you are saying.
> > Indeed. Nevertheless, I'm right at this one :-)
> I defer to your expertise on SQL standards. Regardless of the standard,
> however, mysql does not pad CHARs with spaces. Thus, CHARs and VARCHARs
> are identical from the client's point of view, so silently changing
> CHARs to VARCHARs for tables with variable length rows does not affect
> the client, but does save space and time.
I'm unsure why it saves time. However, they are semantically different.
For example, a VARCHAR "LIKE" is different:
If I would be, for example, storing certain "codes" in a CHAR, and
would do a search like this:
WHERE mychar LIKE 'A %'
This can return rows.
WHERE myvarchar like 'A %'
doesn't. So there IS a difference. If my "code" would be 5 chars long,
always and be, eg, one character and 4 numericals, or less, but padded
with spaces, CHAR would be a good choice. Having this automatically
changed to VARCHAR can get me into trouble.
Even more so when I'm converting from another database engine,
or when I have to support multiple engines. Fact is, CHAR isn't
implemeted properly in MySQL.
>As I understand it, a string
> is a string in mysql. CHAR and VARCHAR are just two string storage
Actually, they're not storage methods. They're logical
things, CHAR is padded, VARCHAR isn't. How they are stored
is something completely different. There's nothing that tells MySQL
(or any database engine, for that matter) to store a CHAR fully
padded. For example, Firebird almost stores CHARs and VARCHARs
the same, but on retrieval pads a CHAR.
> So long as that's true, mysql is doing you a favor when it
> makes this change.
> > Chars should be padded.
> You mean according to the standard, I assume. I am unconvinced changing
> mysql to pad CHARS at this point, at the cost of speed and compatibility
> with existing code, is a good idea.
Well, it certainly is a "gotcha" for new people. Luckily, it's documented,
that's something. But it's still a flaky (or at least: strange)
of the standard CHAR datatype.
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL