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 <
[email protected]> 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 <[email protected]> wrote:
> > On 7 дек 2010, 00:31, Fran <[email protected]> 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.
>
