Aaron Stone wrote:
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.
That's still not an elegant solution. The best solution would be be to
write a constraint or domain in the DB that would prevent uppercase
characters being inserted at all no matter where the insertion is coming
from. Of course, that doesn't help people using MySQL since it isn't
capable of that... of course, IMNSHO, MySQL is not robust enough to be
used as a back end for large scale implementations anyway.
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
