[eluser]Randy Casburn[/eluser]
I don't see why they would object to your proposal unless there are problems with other database platform implementations. We're also going off my assumed reasoning for the hard coded length to be in there in the first place. I could be way wrong. But let's say I'm not, we're simply replacing one hard coded value with another. I do agree that yours makes more sense given the nature of MySQL, the VARCHAR char type charcteristics and the research on known user-agent strings. So if nothing else, it would at a minimum be a less error prone solution for a MySQL based CI system than the one we have today. One of the problems with this analysis is that we're being a little myopic when we only consider the character types for one supported database platform.
So my suggestion would be for you to research the equivalent data types for the other supported DB platforms to determine if they will support this as elegantly as MySQL. If so, search the bug repository, and report this if you don't find anything and point back to this thread (rather than explain it all again). The Dereks will let you know what they think.
I might suggest language such as:
Research at user-agents.org (insert link) suggests the user-agent strings will not exceed the maximum character limit of a VARCHAR or equivalent data types for the CI supported DB platforms. Since VARCHAR or equivalent data types store only data provided, the trim function is unnecessary.
=====
The last sentence is likely to fall flat due to the differences in DB platform capabilities.
Best of luck to you.
Randy
p.s. I can't imagine how this could be interfering with your authentication system.
