Always quote names regardless of whether they are reserved keywords #6294

Open
opened 2026-01-22 15:30:16 +01:00 by admin · 6 comments
Owner

Originally created by @morozov on GitHub (Sep 11, 2019).

Feature Request

Q A
New Feature yes
RFC yes
BC Break no

Currently, DBAL provides lists of platform-specific reserved keywords which the ORM uses in order to decide whether a name needs to be quoted. These lists periodically get out of date which causes issues in applications and therefore it requires an update in the DBAL and in the application dependencies.

On most platforms, quoting can be used safely on any names w/o side effects regardless of whether it's a keyword or not. What would it take to quote names in the ORM unconditionally? This way, the generated SQL would be future-compatible with new platform versions.

Originally created by @morozov on GitHub (Sep 11, 2019). ### Feature Request <!-- Fill in the relevant information below to help triage your issue. --> | Q | A |------------ | ------ | New Feature | yes | RFC | yes | BC Break | no Currently, DBAL provides lists of platform-specific reserved keywords which the ORM uses in order to decide whether a name needs to be quoted. These lists periodically get out of date which causes issues in applications and therefore it requires an update in the DBAL and in the application dependencies. On most platforms, quoting can be used safely on any names w/o side effects regardless of whether it's a keyword or not. What would it take to quote names in the ORM unconditionally? This way, the generated SQL would be future-compatible with new platform versions.
admin added the Improvement label 2026-01-22 15:30:16 +01:00
Author
Owner

@lcobucci commented on GitHub (Sep 12, 2019):

AFAIK this has already been solved for v3. I believe that it has been done in the exact way you described but @guilhermeblanco can clarify things.

Not sure about the feasibility for v2 since people are quoting some things manually and double quoting will generate invalid SQL. We can try to introduce this as a migration step on v2.7.0, just need to design things properly.

@lcobucci commented on GitHub (Sep 12, 2019): AFAIK this has already been solved for `v3`. I believe that it has been done in the exact way you described but @guilhermeblanco can clarify things. Not sure about the feasibility for v2 since people are quoting some things manually and double quoting will generate invalid SQL. We can try to introduce this as a migration step on v2.7.0, just need to design things properly.
Author
Owner

@morozov commented on GitHub (Sep 12, 2019):

I'm glad to hear that. If it's indeed solved for v3, we can remove the corresponding API from DBAL v3 as well.

I believe it was done in 08e2f779e3, however, I don't see any usage of KeywordList or similar APIs. How then did/does ORM use the lists which DBAL maintains?

@morozov commented on GitHub (Sep 12, 2019): I'm glad to hear that. If it's indeed solved for `v3`, we can remove the corresponding API from DBAL `v3` as well. I believe it was done in https://github.com/doctrine/orm/commit/08e2f779e3881f97c8136129fe9f951a9de2cb0d, however, I don't see any usage of `KeywordList` or similar APIs. How then did/does ORM use the lists which DBAL maintains?
Author
Owner

@lcobucci commented on GitHub (Sep 12, 2019):

@morozov I'm not sure but I think the ORM has never used KeywordList. Looking at DBAL repo history it seems that was only created to support the command Doctrine\DBAL\Tools\Console\Command\ReservedWordsCommand (added in DBAL v2.1.0RC1).

Perhaps @beberlei might be able to give some more info?

@lcobucci commented on GitHub (Sep 12, 2019): @morozov I'm not sure but I think the ORM has never used `KeywordList`. Looking at DBAL repo history it seems that was only created to support the command `Doctrine\DBAL\Tools\Console\Command\ReservedWordsCommand` (added in [DBAL v2.1.0RC1](https://github.com/doctrine/dbal/commit/aceb3eebdf69798d9dea34c200939f703e818846#diff-ef92c2ffbadb3ffe255a2a20308a6b63)). Perhaps @beberlei might be able to give some more info?
Author
Owner

@morozov commented on GitHub (Sep 12, 2019):

Then I'm really curious where all the tickets like "Add new keywords for $platform v$x+1" come from. There must be some widely used components which rely on those lists to decide whether a name needs to be quoted. I want to get them quoted always instead.

@morozov commented on GitHub (Sep 12, 2019): Then I'm really curious where all the [tickets](https://github.com/doctrine/dbal/issues?utf8=%E2%9C%93&q=label%3A%22Reserved+Keywords%22) like "Add new keywords for $platform v$x+1" come from. There must be some widely used components which rely on those lists to decide whether a name needs to be quoted. I want to get them quoted always instead.
Author
Owner

@beberlei commented on GitHub (Jan 7, 2020):

The Schema component uses the keyword list and its mostly required when not used with ORM when fetxhing a legacy schema that uses reserved words as identifiers.

As for ORM its not necessarily good to auto quote because the non quoted behavior bs quoted varies widely in platforms and code would become less portable as a result. Remember that:

  • Oracle auto strtoupper unquoted columns
  • Postgees auto strtolower unquoted columns
  • Mysql depends on ini setting, bur by defsult is case sensitive without changing cases

Doctrine 1 auto quoted, and this caused a lot of pain. I don‘t know which solution would be the less painful one

@beberlei commented on GitHub (Jan 7, 2020): The Schema component uses the keyword list and its mostly required when not used with ORM when fetxhing a legacy schema that uses reserved words as identifiers. As for ORM its not necessarily good to auto quote because the non quoted behavior bs quoted varies widely in platforms and code would become less portable as a result. Remember that: - Oracle auto strtoupper unquoted columns - Postgees auto strtolower unquoted columns - Mysql depends on ini setting, bur by defsult is case sensitive without changing cases Doctrine 1 auto quoted, and this caused a lot of pain. I don‘t know which solution would be the less painful one
Author
Owner

@morozov commented on GitHub (Jan 7, 2020):

The Schema component uses the keyword list and it's mostly required when not used with ORM when fetching a legacy schema that uses reserved words as identifiers.

Is it necessary for the schema component to know which identifiers are keywords and which aren't? I believe, for those platforms that make a difference between quoted and non-quoted identifiers, there must be a way to see if a given identifier is quoted or not and handle it accordingly. Although, I may be wrong.

Doctrine 1 auto quoted, and this caused a lot of pain.

What kind of pain was that? Is it something like once you let ORM auto-quote all identifiers (e.g. SELECT "date" FROM "user") on Oracle, you'll have to write all queries using quoted identifiers because they become case-sensitive?

My point here is that regardless of the approach, you still have to quote some identifiers and they inevitably become case-sensitive. Why not make this experience consistent? At least, this way, you will no longer depend on how up to date the keyword dictionaries are in DBAL.

@morozov commented on GitHub (Jan 7, 2020): > The Schema component uses the keyword list and it's mostly required when not used with ORM when fetching a legacy schema that uses reserved words as identifiers. Is it necessary for the schema component to know which identifiers are keywords and which aren't? I believe, for those platforms that make a difference between quoted and non-quoted identifiers, there must be a way to see if a given identifier is quoted or not and handle it accordingly. Although, I may be wrong. > Doctrine 1 auto quoted, and this caused a lot of pain. What kind of pain was that? Is it something like once you let ORM auto-quote all identifiers (e.g. `SELECT "date" FROM "user"`) on Oracle, you'll have to write all queries using quoted identifiers because they become case-sensitive? My point here is that regardless of the approach, you still have to quote _some_ identifiers and they inevitably become case-sensitive. Why not make this experience consistent? At least, this way, you will no longer depend on how up to date the keyword dictionaries are in DBAL.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6294