I was helping a fellow coder yesterday, and he was having problems with a simple comparison statement. The situation he found himself in was this:

A $_POST value could either be 0 (zero) or a text string. If incoming value was 0 (zero) that meant a new record needed to be inserted in the database, if it was a text string then the record already existed in the database and needed to be updated. Consequently he wrote his comparison statement like this:

<?php
 
if ($_POST["id"] == 0) {
    //insert db record
}
else {
    //update db record
}
 
?>

Everything looked fine to him, but no matter what value was passed in the $_POST variable the comparison statement evaluated to TRUE, meaning a new record was inserted into the database.

If you want to check it out yourself run this code:

<?php
 
$_POST["id"] = "0";
 
if ($_POST["id"] == 0) {
    echo "insert db record / ";
}
else {
    echo "update db record / ";
}
 
$_POST["id"] = "string of text";
if ($_POST["id"] == 0) {
    echo "insert db record";
}
else {
    echo "update db record";
}
 
?>

If you run the code above it will print: ‘insert db record / insert db record’.

Now this is a bad comparision to begin with, since all values coming from $_POST are a string of text; but that was not the problem he was experiencing.

Why does “string of text” equal zero in the second comparision statement?…. because of TYPES, of course.

In the both comparison statements we are comparing a string and an integer, since we did not use the Identical comparison operator (===), PHP converts the string to an integer before making the comparison. This means it is the same as casting the string as an integer then making the comparison; such as:

<?php
 
$_POST["id"] = "string of text";
$_POST["id"] = (int)$_POST["id"];
 
if ($_POST["id"] == 0) {
    echo "insert db record";
}
else {
    echo "update db record";
}
 
?>

When casting “string of text” as an integer “string of text” becomes 0 (zero). Check it out:

<?php
 
$_POST["id"] = "string of text";
$_POST["id"] = (int)$_POST["id"];
 
var_dump($_POST["id"]);
 
?>

The above code will print: “int(0)”.

So how do we get this comparison to evaluate as intended? We cannot use the Identical (===) comparison operator, because as I said before, everything coming from $_POST is a string. This means we would have the same problem in reverse. The comparison would always evaluate to FALSE, and it would attempt to update records that do not exist. What we need is for PHP to evaluate both operands as strings, this can be accomplished two ways. Either by placing quotes around the 0 (zero) making it a string, or casting the 0 (zero) as a string. Such as:

<?php
 
if ($_POST["id"] == "0") {
    //insert db record
}
else {
    //update db record
}
 
if ($_POST["id"] == (string)0) {
    //insert db record
}
else {
    //update db record
}
 
?>

Personally I think the first example is more appropriate, if you want to compare 0 (zero) as a string just write it as a string. I simply provided the casting example because we have previously discussed casting.

If you would like to know more about Types in PHP you can read my previous post: Variable Types – Why Care? and follow the links at the bottom of the article.

PHP – Manual
The type of a variable is usually not set by the programmer; rather, it is decided at runtime by PHP depending on the context in which that variable is used.

In code terms this means that we do not have to define a “type” for each variable, we can simply give the variable a value and the PHP engine will determine (through context clues) what the variable type should be at that instant (runtime). Also a variable’s type may change any number of times during the execution of a script, as shown by this example:

<?php
//the variables are defined as strings
//(with quotes)
 
$integer1 = "50";
$integer2 = "14";
 
//we can use them
//in mathematical equations
 
echo $integer1 + $integer2; //64
 
//we can also treat them
//as strings and concatenate them
 
echo $integer1 . $integer2; //5014
 
//if we want to get fancy we can also use
//them as arrays, which actually comes in
//handy once in a while
 
echo $integer1[0] + $integer2[0]; // 6
//**note if the variables were defined as
//integers this last example would not
//work**
?>

Given this information, most PHP developers (especially those who use PHP exclusively) simply forget about variable types and PHP does all the work for them. I was one of those developers until I read an article (unable to locate the link at the moment) about optimizing your PHP code.

In the article the benchmarks showed a significant improvement in processing time when using the comparison operators Identical (===) and Not Identical (!==) as opposed to Equal (==) and Not Equal (!=).

**Please note I have no idea if this optimization still true, or ever was, but for our purposes it really does not matter.**

The difference between (Not) Identical and (Not) Equal is that PHP checks both the value and type of the two operands, meaning:

<?php
//integer1 is defined as a string
$integer1 = "50";
 
//integer1 is defined as an integer
$integer2 = 50;
 
if ($integer1 == $integer2) {
    echo "Equal / ";
}
else {
    echo "NOT Equal / ";
}
 
if ($integer1 === $integer2) {
    echo "Identical";
}
else {
    echo "NOT Identical";
}
?>

The above code will print “Equal / NOT Identical”. During the first comparison (equal), type is not taken into consideration so the string “50″ is equal to the integer 50; but in the second comparison (identical), a string and an integer are not the same, hence not identical.

Obviously when you start comparing two values using the (Not) Identical operator, type becomes very important and a little challenging at first. You will inevitably forget to take into consideration variable types, and some code will simply not execute as you planned.

OK, so now that I have briefly explained types (string and integer) in PHP terms, the question remains, why do we care? Simply put: because it is part of PHP. If you just want to create scripts which randomly display quotes, email the contents of a form, or other small tasks then there really is no reason to get involved with types or type casting; but since you are reading this post (and have made it this far) I will assume you are slightly more interested in creating larger projects and applications. If this is the case then you need to learn about all aspects of PHP and in tern you will then be able to write more complicated, efficient and stable code.

As a quick example: you should know that all data coming from $_POST and $_GET arrives in PHP as stings (actually an array of strings; kind of like field values from MySQL ). So if you would like to check that an incoming value is numeric, you could use the function is_numeric() or ctype_digit(). Of course if you wanted to determine if a value is numeric one of the quickest and most efficient ways is to cast the value.

Since 99% of the time 0 (zero) is not a valid value for incoming numeric data you can simply cast the variable. If the value only contains non-numeric characters; when cast as an integer PHP will set the value to 0 (zero). If the value is entirely numeric or begins with a number the numeric portion is converted. For example:

<?php
$id = (int)$_POST["id"];
if (0 === $id) {
    echo "NOT Numeric";
}
else {
    echo "Numeric";
}
?>

*Note: When casting a value please be sure to cast the value to the correct type.

If you would like to learn more about Types and Casting, here are some links to sections of the PHP Manual:
Types
Type Casting
Variable Handling Functions

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?