Re: mysqli_fetch_field() mysqlnd & libmysql differences

Hi, On Sep 6, 2012, at 1:24, Daniel Convissor <danielc@analysisandsolutions.com> wrote: > Hi Johannes: > > On Thu, Jan 19, 2012 at 01:50:47PM +0100, Johannes Schlüter wrote: >> >> unsigned long length >> >> The width of the field. This corresponds to the display length, >> in bytes. >> >> The server determines the length value before it generates the >> result set, so this is the minimum length required for a data >> type capable of holding the largest possible value from the >> result column, without knowing in advance the actual values that >> will be produced by the query for the result set. >> >> >> http://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html > > Pardon me for looping back around to this old discussion. I had a > moment to look at this in PEAR::DB the other day. A new perspective > came to mind... > > It seems the field length in the C API is there to aid C programmers > with memory allocation. > > The field length in PHP is there for PHP programmers to reverse engineer > database structures. > > These are different purposes and the output should reflect such. > > For example, the userland PHP field length could lead to someone dumping > a structure that has a VARCHAR(10). The exported metadata would say > VARCHAR(30). Then it gets imported and dumped again, and now we're up > to VARCHAR(90). Not fun. This is all correct - but there isn't much we can do. The server provides this data. Trying to "fix" it on the client side will likely become a mess. If we create a mess I prefer doing it in user land (db2, mdb, doctrine, propel, ...) where "everybody" can debug/fix it. Johannes > Thanks for your reconsideration, > --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