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] <javascript:>> > 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] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > 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.
