Re: not aborting transactions on failed select - Mailing list pgsql-general
| From | Sergey Shelukhin |
|---|---|
| Subject | Re: not aborting transactions on failed select |
| Date | |
| Msg-id | CAHXxaiBYMc9n42YCFxWYU6A5bsLMWoBjG3Yb3SnTpFjbS8zaAA@mail.gmail.com Whole thread Raw |
| In response to | Re: not aborting transactions on failed select (Alban Hertroys <haramrae@gmail.com>) |
| Responses |
Re: not aborting transactions on failed select
(David Johnston <polobo@yahoo.com>)
|
| List | pgsql-general |
Folding to uppercase is according to standard, lowercase no, so in our case we could expect it to work if we have uppercase tables... in fact, it should work whether FS is case sensitive or not in MySQL, tables are created and used uppercase.
Due to presence of a large number of historical installations renaming all the tables is not viable.Again, as I said, this is not the problem here, we'll figure out how to deal with the queries in this case. Probably put in quotes and switch MySQL to ANSI mode within session, some testing would be needed to see how it affects ORM.
But the problem is that even when queries work, for the future potential breakage the fall-back to ORM should always work... and it doesn't.
On Wed, Sep 11, 2013 at 12:57 AM, Alban Hertroys <haramrae@gmail.com> wrote:
On 11 September 2013 07:53, Sergey Shelukhin <sergey@hortonworks.com> wrote:The query suffers from the auto-lower-casing of unquoted table names, which is not ANSI compliant. Technically we could add quotes (and stay ANSI), but then MySQL would break without explicitly setting it to use ANSI mode, so it's a lose-lose situation if we do not want to have DB-specific code.Whether identifiers get folded to lower case or to upper case (which IS according to the standard) should not matter to you.
If you're using case sensitive table names, the standard says to quote your identifiers.
It would appear that MySQL is doing something non-standard compliant that's biting you here.
I haven't used MySQL in 10 years, but if memory serves me correctly, it tends to use the literal file name of the table, which would be case-sensitive on a case-sensitive file system. I remember the hilarity of the same issue when we moved a MySQL database from a file system that was not case sensitive (NTFS) to one that was (EXT2FS) - we had to rewrite all our queries because MySQL could no longer find the tables in our queries. That was when we wrote off MySQL for the project we were working on back then.From your remark it isn't entirely clear what your problem is; it would appear that your ORM is generating case-sensitive table names and that your query outside the ORM assumes that it doesn't need to quote those identifiers?Perhaps your ORM can be told not to do that?
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
pgsql-general by date: