One of the first things you should learn as a developer (or human) is to never assume, so I checked the documentation, and to my surprise I was completely wrong, the number actually arrives in PHP as an INT type.

The MySQL C API function mysql_num_rows() returns a my_ulonglong value:

MySQL – Paul DuBois
my_ulonglong – A long integer type, used for the return value of functions that return row counts or other potentially large numbers, such as mysql_affected_rows(), mysql_num_rows(), and mysql_insert_id()…

This information again had me looking through the documentation in the PHP manual and in fact mysql_insert_id() does return an INT type (or FALSE on failure).

I find it interesting that in certain situations the data type coming from the MySQL C API is actually representative of the content of the data and at other times it is not. Not that this gets us any closer to why field values are all returned as strings, but the plot does thicken.

If anyone can shed any light on this topic, or would like to put their own spin on things, please feel free to comment.

In the next couple of days I will write a post explaining how, as a PHP developer, I became interested in variable types, and why you should also.

When querying data out of MySQL into PHP, all values arrive in PHP as strings, even if the MySQL column type is INT. This is documented behavior:

PHP Manual – mysql_fetch_array…
Returns an array of strings that corresponds to the fetched row…

I understand that PHP is a loosely typed language, which means PHP will convert the string to an integer on the fly (if it is deemed appropriate); but my question is: Why do integers arrive in PHP as strings?

A little research into the topic shows that the integer to string conversion actually happens outside the scope of PHP and lies in the MySQL C API. The mysql_fetch_row() function (within the C API) returns the data type MYSQL_ROW, which is defined as:

A type-safe representation of one row of data. It is currently implemented as an array of counted byte strings. (You cannot treat these as null-terminated strings if field values may contain binary data, because such values may contain null bytes internally.) Rows are obtained by calling mysql_fetch_row().

I have asked in a few forums and chat rooms about this, but was never really able to get a definitive answer. Most people say that since PHP is loosely typed it doesn’t matter, which I cannot accept as an answer, especially since the MySQL C API is not used exclusively for loosely typed languages.

One theory I heard is that since the C API is used in many different languages for connecting to MySQL, the creators decided it would simply be easier to return all values as strings. This could possibly be the case, but I do not know of a common language which could not handle an integer.

Has anyone else looked into this topic before, or do you have the answer that has eluded me?

I decided to release the Mysql Package first. This was done for three reasons.

• Usefulness – After using PHP for a few days everyone inevitably wants to add a database to there repertoire. Since the most common database coupled with PHP (by my calculation) is MySQL why not create a MySQL package.
• Basic – The package I created is very basic giving novices a chance to get up and running quickly, and to see what OOP is all about.
• Example of my work – I understand that if you are no longer a PHP novice you will already have a database package which you use and prefer, but by releasing this package first, you will be able to review the code quickly and determine the quality of code I produce. Hopefully this will keep you interested in my growing library.

A little about the Mysql Package:
The package is designed to provide basic functionality for connecting, querying, data retrieval, and error reporting against a MySQL database server.

The package is divided into 4 main classes (with a fifth typed exception).

Hope you all enjoy, and keep those comments coming.

Thank you.