On 29 янв, 04:53, Thadeus Burgess wrote:
> IMHO This breaks backwards compatibility...
If .like() should match case-insensitive then this is bug fix.
At http://web2py.com/book/ this does not specified explicitly.
PS. .ilike for case insensitive? I think the question is, to make it
available for
On 29 янв, 05:39, Bernd Rothert wrote:
> On 28 Jan., 16:46, Thadeus Burgess wrote:
>
> > Case sensitive search is one of the benefits of using postgres instead of
> > mysql!
>
> As Fran wrote case insensitive LIKE is just a default for MySQL and
> sqlite. MySQL supports case sensitive search:
Thi
On 28 Jan., 16:46, Thadeus Burgess wrote:
> Case sensitive search is one of the benefits of using postgres instead of
> mysql!
>
As Fran wrote case insensitive LIKE is just a default for MySQL and
sqlite. MySQL supports case sensitive search:
# SELECT * FROM person WHERE name LIKE BINARY '%Pi%';
IMHO This breaks backwards compatibility...
--
Thadeus
On Sat, Jan 29, 2011 at 6:31 AM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:
> I treat this as a bug fix.
>
> On Jan 28, 12:52 pm, Anthony wrote:
> > On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote:
> >
I treat this as a bug fix.
On Jan 28, 12:52 pm, Anthony wrote:
> On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote:
>
> > We need two steps:
>
> > 1) make it behave the same (which means case insensitive, ilike on
> > postgresql, now in trunk)
>
> Doesn't this change break ba
ILIKE is not the same as containing. It is a case insensitive LIKE
On Jan 28, 12:23 pm, villas wrote:
> I suppose 'ilike' in PostgreSQL is similar to 'containing' in Firebird
> (except you don't use wildcards in FB).
>
> On Jan 28, 5:58 pm, Massimo Di Pierro
> wrote:
>
>
>
>
>
>
>
> > We need tw
On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote:
>
> We need two steps:
>
> 1) make it behave the same (which means case insensitive, ilike on
> postgresql, now in trunk)
Doesn't this change break backward compatibility, or are you treating this
as a bug fix?
> 2)
I suppose 'ilike' in PostgreSQL is similar to 'containing' in Firebird
(except you don't use wildcards in FB).
On Jan 28, 5:58 pm, Massimo Di Pierro
wrote:
> We need two steps:
>
> 1) make it behave the same (which means case insensitive, ilike on
> postgresql, now in trunk)
> 2) yes we can add
We need two steps:
1) make it behave the same (which means case insensitive, ilike on
postgresql, now in trunk)
2) yes we can add a case_sensitive arg that defaults to True (not done
yet but I would take a patch).
On Jan 28, 11:37 am, Anthony wrote:
> What if like() had something like a 'case' a
What if like() had something like a 'case' argument, with three possible
values: sensitive, insensitive, and rdbms_default (defaulting to
rdbms_default)?
We obviously need to maintain backward compatibility, but like() is a web2py
operator, not a specific RDBMS operator, so it would be nice if
I agree with Thadeus here that "like" should be what it means in each
case. Changing the default meaning of "like" in each RDBMS will cause
confusion. "ilike" can be a web2py thing, but "like" should be
specific to each RDMS.
On Jan 28, 9:46 am, Thadeus Burgess wrote:
> I disagree! Your playi
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%')
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 wrote:
> On 7 дек 2010, 00:31, Fran wrote:
>
> > - minimally it should be in a FAQ (ideally in the next Book) & ideally
On 7 дек 2010, 00:31, Fran 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
14 matches
Mail list logo
