Re: not aborting transactions on failed select

From: Sergey Shelukhin <sergey(at)hortonworks(dot)com>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: not aborting transactions on failed select
Date: 2013-09-11 14:52:49
Message-ID: CAHXxaiBYMc9n42YCFxWYU6A5bsLMWoBjG3Yb3SnTpFjbS8zaAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)com> wrote:

> On 11 September 2013 07:53, Sergey Shelukhin <sergey(at)hortonworks(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Johnston 2013-09-11 15:23:36 Re: not aborting transactions on failed select
Previous Message Eduardo Morras 2013-09-11 14:49:32 Re: Call for design: PostgreSQL mugs