Escape identifiers in metadata SQL properly when used as string literal

[deeky666]

Closes #2436

@Ocramius I tried to write tests but neither of my approaches felt right. First I tried to assertContains() the resulting SQL but that is not applicable to all platforms and methods as the given identifiers to escape are not always used as string literals (heavily depends on the platform's SQL statement) or are not even used at all. Then I tried to write functional tests but that is problematic, too as I cannot test the $database identifiers properly on all platforms because that involves creating a database (which is heavy and not supported on all platforms) with escape characters in the name.

Any idea what test to write here or should we take it "as is"?

[kimhemsoe]

I agree that it is a bug, but this very much looks like a BC break for me. If i remember correct i even wrote a few scripts many years ago where i hit this and worked around it by calling quote manually. If ive have done that possible others have as well.

[deeky666]

@kimhemsoe yeah but it is wrong to do a quoteStringLiteral() for an identifier before passing it to the getList*SQL() methods because whether or not the identifier is treated as string literal is implementation detail and platform specific. The user should not know how the underlying SQL is built. Also the platform API does not make any statements about whether a given identifier should be quoted/escaped or the like. So I don't think this is a BC break but rather a misuse of the API then. It would be wrong if the (mis)usage of our API prevents us from fixing bugs.

[Ocramius]

@deeky666 I don't think that there is a sensible way to test this. I'd still apply some minimal assertions around the identifiers inside the SQL though, as that would show BC breaks in the quoting immediately, even though the tests may seem fragile.

[deeky666]

@Ocramius done.

[Ocramius]

Merged!

master: b6b247a
2.5: 4bca226

[deeky666]

@Ocramius thanks