Standardise escaping of table, field and aliases in database layer

Im still going through this patch (much needed),

I think I spotted one typo, introduced on the includes/database/select.inc tweaks: 'hasAnyTags' by 'hasAnyTag' around line 599 or so

nevermind about the typo, this must be a diff between my stable and the dev. target. difference exists, but not due to this patch..

This patch works for my use case, THANKS!

We query external databases that may not follow long-standing database conventions. For example, many table column labels may have all sort of non standard characters. Specifically, what triggered my interest in the patch was to deal well with the " " blanks in column names. Those blanks are currently ignored by Drupal, and the resulting (select) query fails. OK, unclear still? I query an external database table that has a column on called DISCHARGE RATE, Drupal converts this in the process to DISCHARGERATE, but of course, such column does not exist in the external table, query fails. boo.

Incidentally, we use of the Dave Reid's contrib schema_reference to expose external databases to Drupal via field, then use other custom modules to produce all sort of queries.

Your patch works for me in this very specific case: i did not run a full suite of tests against other characters, 'creative' table names, other databases such as pgsql or sqllite.

One thing, I am working with stable, so I adapted the change at includes/database/mysql/database.inc (which was rejected).. It seems in dev, there is extra checks in the line of code on the line 92. What I did is use the escapeTable in the corresponding line, that did the trick. (and flushing some caches, just in case)

    $this->query('CREATE TEMPORARY TABLE {' . $this->escapeTable($tablename) . '} Engine=MEMORY ' . $query, $args, $options);

Thanks for the patch -- I may add more cases as I encounter them to verify that this works in more cases.

We've just found this issue with my colleagues when we were trying to define / use a new entity type. I've triggered it fairly easily by doing to following:

1. Use ECK to create a new entity type.
2. Add a new property with a machine name which is a reserved word - in our case, it was "show" and enable it.
3. Try to add a new entity with the type just created - it will fail with the PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 message.

As far as I can see, this is still an issue in D8, so I've bumped the version.

I think this is a duplicate of #1426084: Provide backtick escaping for MySQL in DB abstraction layer.