Redshift has all kinds of limitations and weird behaviors. They developed it as a simplified cloud db only generally based off of Postgres.
Sent from my iPhone > On Oct 10, 2013, at 11:11 PM, Wu Jiang <[email protected]> wrote: > > Yes. Thank you, Michael. Still wondering why Redshift is case insensitive. > >> On Thursday, October 10, 2013 5:22:23 PM UTC-4, Michael Bayer wrote: >> so send case_insensitive=True to create_engine() , all the result-row >> targeting will be done case insensitively - fixes the issue ? >> >> >>> On Oct 10, 2013, at 4:46 PM, Wu Jiang <[email protected]> wrote: >>> >>> It seems to only happen when we connect to Amazon Redshift. According to >>> Redshift doc >>> (http://docs.aws.amazon.com/redshift/latest/dg/r_names.html), delimited >>> identifiers are >>> case insensitive. >>> >>>> On Thursday, October 10, 2013 2:06:09 PM UTC-4, Michael Bayer wrote: >>>> can you produce a test case? can you get the short test I sent to produce >>>> the failure condition ? >>>> >>>> >>>> On Oct 10, 2013, at 1:24 PM, Ryan Kelly <[email protected]> wrote: >>>> >>>> > On Thu, Oct 10/10/13, 2013 at 12:59:31PM -0400, Michael Bayer wrote: >>>> >> >>>> >> On Oct 10, 2013, at 8:34 AM, Ryan Kelly <[email protected]> wrote: >>>> >> >>>> >>> Hi: >>>> >>> >>>> >>> One of our applications is generating the following error: >>>> >>> >>>> >>> NoSuchColumnError: "Could not locate column in row for column >>>> >>> 'client.claims.client_id'" >>>> >>> >>>> >>> Which is rather strange, because that column is aliased with .label() >>>> >>> to >>>> >>> "AS Client_ID", so of course that row cannot be located. >>>> >> >>>> >> when the SQL is actually rendered, is the "Client_ID" name rendered >>>> >> with quotes? it should be, as that is a case-sensitive name. >>>> > Yes, the SQL is correctly quoted. >>>> > >>>> >> 0.8 made a change regarding upper/lower case names which is that we no >>>> >> longer call lower() on identifier names when producing lookup >>>> >> dictionaries for result rows - see >>>> >> http://docs.sqlalchemy.org/en/rel_0_8/changelog/migration_08.html#case-insensitive-result-row-names-will-be-disabled-in-most-cases >>>> >> >>>> > >>>> >> or the failure here might have something to do with a conflicting >>>> >> "client_id" name elsewhere in the query. >>>> > It's the only one. >>>> > >>>> >> you might want to see is sending "case_sensitive=False" to >>>> >> create_engine() restores the working behavior you saw in 0.7. >>>> >> it does sound like something originating within your query and how >>>> >> SQLAlchemy handles it, psycopg2 is unlikely to be playing a role here. >>>> > I guess I will poke around some more. >>>> > >>>> > -Ryan Kelly >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sqlalchemy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/sqlalchemy. >>> For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
