I disagree! Your playing with things that shouldn't be played with. Not to mention that now you have just broken some of my apps that perform case-sensitive queries in postgres.... this is just plain wrong in so many ways.
Add a new identifier to DAL... give me db(db.table.name.like('%printer%')) and then for case insensitive db(db.table.name.ilike('%printer%')). like would perform the actual operation that would happen from the RDBMS, and ilike can be a web2py playing god version that makes sure all rdbmses act the same. Case sensitive search is one of the benefits of using postgres instead of mysql! -- Thadeus On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro < massimo.dipie...@gmail.com> wrote: > I agree the behavior should be uniform. The easiest way is to make the > LIKE always case insensitive. I am patching trunk to use ILIKE with > postgresql. > > On Jan 28, 3:01 am, KMax <mkostri...@gmail.com> wrote: > > On 7 дек 2010, 00:31, Fran <francisb...@gmail.com> wrote: > > > > > - minimally it should be in a FAQ (ideally in the next Book) & ideally > > > we could have a case_sensitive=True option for the DAL like() > > > operator...to ensure that both pgsql & mysql/sqlite existing apps > > > didn't break, it could default differently depending on the db type? > > > > +1 vote > > sqlite has some issue with not ascii chars compare, but work in > > progress > > pgsql has ilike which works like mysql like (fix me) > > > > I' just patch dal to use ilike in .like() query for postgres, but it > > more cheat then solution. >