Re: Re: cvs: pear /DB/DB dbase.php fbsql.php ibase.php ifx.php msql.php mssql.php mysql.php mysql4.php oci8.php odbc.php pgsql.php sqlite.php
sybase.php

On Fri, Jan 02, 2004 at 06:04:22PM +0100, Pierre-Alain Joye wrote: > We are not talking about what's is the best way to implement the > 'portability' flag but about how these methods work before. > > Again, howmany users of DB with mysql backend? 80%? 90%? And how many of > them use the portability flag with uppercase column names? I understand your point. Two points for further discussion... All portability does in MySQL is add "1=1" to DELETE queries. Doesn't seem to me that people would have portability on just for that, so changing portability behavior wouldn't likely do much. Also, there's another difference between DBMS's that I'm looking to eliminate with the portability flag: padding of strings. Most DBMS's pad the output of CHAR fields to the full length of the field. But some don't. I was planning to put a call to rtrim() when portability is on. In this light, if we are going to use a new name, the new option should be called something more generic than "lcasekeys" or whatever. I think adding a new option name for this obfuscates things. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409