On Thu, Dec 28, 2006, jake anderson <[EMAIL PROTECTED]> said:
> Paul J Stevens wrote:
>> Michael Monnerie wrote:
>>
>>> I have this log:
>>> dbpgsql.c,db_query(+279): [SELECT deliver_to FROM dbmail_aliases WHERE
>>> lower(alias) = lower('[EMAIL PROTECTED]') AND lower(alias) <>
>>> lower(deliver_to)]
>>>
>>> couldn't you write ....'AND alias <> deliver_to'? I mean, skip
>>> the "lower()' twice? Just force entries in that table to be lower()
>>> already. I heard in some RFC they say that upper/lowercase should be a
>>> difference, but I never saw that in live use.
>>>
>>
>> That's incorrect. Email addresses are case-insensitive. And no, we
>> cannot be sure the values entered are indeed lower-case, unless we setup
>> a trigger.
>>
>> Postgres allows you to 'create index lower(column)' which will resolve
>> the performance issues here.
>>
>>
>>
> I think the OP was saying to programatically insert into the table in
> lower, then postgres and mysql (and any other db you care to name) can
> play with it without conversion, yes there is some data "lost" but its
> insignifigant.
You're reading the OP correctly, but I would still do the lookups with
forced lower case because the data might have been inserted by someone
other than the dbmail-users program. I would prefer not to have to specify
"if you write a third party tool, always make sure to insert lowercase
data into this column" if we can just as easily enforce that in the
queries. Making sure to build the index with the lowercased values is the
big issue I think.
Aaron
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
