Do we want Bugzilla to be case-sensitive or case-insensitive?

[Christopher Hicks]

On Thu, 3 Nov 2005, Frédéric Buclin wrote:
> On IRC, some of us came to the conclusion that choosing either PostgreSQL or 
> MySQL is a strategical choice, depending of what companies want in terms of 
> intrinsic properties. In the same way some users like *nix 
> case-sensitiveness, some others prefer windows case-insensitiveness.

I understand that to some degree both have their place and that where that 
is depends on some degree to personal taste.  But I think pretending its a 
taste issue and ignoring the actual benefits and difficulties in each case 
is unwise.  When dealing with human names, book titles, and other thing 
where case is key, having case sensitivity is not an option.  When dealing 
with product names, SKU's and other things that are much more relevant to 
bugzilla allowing two things to be named the same thing with only varying 
case it seems clear that whatever border cases might be assisted by case 
sensitivity the vast majority is server better by case insensitivity.  By 
choosing to go the convenient way for most as the officially accepted 
bugzilla behavior it seems like we'll minimize confusion and support 
hassles down the road.

As far as choosing between PostgreSQL and MySQL as a strategic decision 
its sort of funny to me.  I've been using Class::DBI and its relatives for 
some time now to write code that's portable between Oracle, MySQL, and 
PostgreSQL because I tired of fighting the same old religious battles time 
and time again.  Perl has a long history of supporting database 
portability to various degrees.  The only real strategic choice here is 
whether to care about database portability or not.  Beyond that its only 
determining which portion of humanity you're going to piss off by not 
choosing their ice cream flavor.

> Forcing all comparisons to be case-insensitive would require to rewrite 
> 98% of all SQL queries!! .... or to find another way to force Pg to be 
> case-insensitive. But it appears that is *not* possible to change this 
> behavior in PostgreSQL, at all. I don't know how Oracle behaves, though.

This is where having a useful abstraction layer makes life much better. 
The fact that there are so many arbitary queries lying around to be fixed 
in this case is a sign of a poor design decision.  Why not re-examine the 
way that the database layer is done.  DBIx::Class is being actively 
maintained by smart folks these days and is very compatible with 
Class::DBI if you want it to be.  This won't solve every issue of this ilk 
and there will need to be occassional optimizations, but in practice we 
haven't had to make many exceptions.

> No matter what we choose, it won't be a simple problem to fix. :(

So lets choose a good futureproof solution so folks are motivated to get 
rid of the old and bring in the new and split up the work.  :)

-- 
</chris>

John Lundin once shaped the electrons thusly:
> Ah. Okay, on the "nice to do" list. (Which in practice translates to
> "won't do unless it becomes inconvenient or is fixed upstream.")