Kristian Nielsen wrote:
> In any case, I think this should be considered a bug (if a documented one
> :-). If I can create a table/column ` t` or `t t`, there is no reason I should
> not be able to create also `t `.
IMHO, there is no real need to have blanks in table names or any other
identifiers (and the same holds for file names, BTW).
I know that MySQL supports this feature (as do file systems), so
Pandora's box has been opened already.
And as such blanks are allowed, they better work properly.
> These kind of special exceptions create no value, and lots of unnecessary
I tend to agree on that part.
> Similarly, I have always been really annoyed that MySQL has no collation that
> make trailing spaces significant in VARCHAR. The fact that ("X" = "X ") in
> eg. utf8_bin is just a glaring bug in my opinion. Let the user decide whether
> they want space to have special significance, not the Database.
This is a tricky issue from the semantics point of view.
I don't have the reference handy, so I can't quote verbatim, but I do
remember that the X/Open standard for SQL specifies something like
"All character strings are comparable.
If character strings are of different length, then the shorter one is
conceptually padded with blanks at the end before comparison."
This exactly means that "X" == "X ", for any "X".
Granted, X/Open does not mention different collations, so you could have
a collation that provides a different semantics, but that would make
matters even more complex.
> Can we fix it? Please?
IMO, there might be users who rely on this, so fixing it is a functional
change which might break things for them. I have no idea how that might
be handled with annoying them.
Joerg Bruehe, MySQL Build Team, Joerg.Bruehe@stripped
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028