ID: 989
Updated by: jimw
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Feature/Change Request
Assigned To:
Comments:
Previous Comments:
---------------------------------------------------------------------------
[1999-12-13 15:44:29] [EMAIL PROTECTED]
Zeev, Andi, or Rasmus:
I know you're busy, but this one is over my head...could you take a sec and explain
the reasoning?
---------------------------------------------------------------------------
[1998-12-14 14:42:39] [EMAIL PROTECTED]
As it was in the original PHP v2.0 the support for the many mysql datatypes is
pitifully incomplete.
In the original 2.0, I had to go in and manually code in the missing data types, as in
that case it was merely an omission of some of newer data type names.
In the new 3.0 code, I find that it is even more pitiful in that all the multitude of
data types available in mysql.c have been truncated to the one or two different types
as seen fit by whoever decided those were the only types supported. How is a PHP
application to know the limits of a field when you only supply int as a datatype
whereas mysql supports 3 sizes of INTs. And the list goes on. Here is the culprit
section of mysql.c -- please do something about it because without this fix, one would
not be able to properly manage a MYSQL database from a PHP web page. I wonder if
anyone thought about that.
tatic char *php3_mysql_get_field_name(int field_type)
{
switch(field_type) {
case FIELD_TYPE_STRING:
case FIELD_TYPE_VAR_STRING:
return "string";
break;
#ifdef FIELD_TYPE_TINY
case FIELD_TYPE_TINY:
#endif
case FIELD_TYPE_SHORT:
case FIELD_TYPE_LONG:
case FIELD_TYPE_LONGLONG:
case FIELD_TYPE_INT24:
return "int";
break;
case FIELD_TYPE_FLOAT:
case FIELD_TYPE_DOUBLE:
case FIELD_TYPE_DECIMAL:
return "real";
break;
case FIELD_TYPE_TIMESTAMP:
return "timestamp";
break;
case FIELD_TYPE_DATE:
return "date";
break;
case FIELD_TYPE_TIME:
return "time";
break;
case FIELD_TYPE_DATETIME:
return "datetime";
break;
case FIELD_TYPE_TINY_BLOB:
case FIELD_TYPE_MEDIUM_BLOB:
case FIELD_TYPE_LONG_BLOB:
case FIELD_TYPE_BLOB:
return "blob";
break;
case FIELD_TYPE_NULL:
return "null";
break;
default:
return "unknown";
break;
}
}
-----------------------------------------------------------------
If ignorance is bliss, I want a painful headache so at least I know what I'm aiming
at. What about you folks?
P.S. VAR STRING and STRING are still 2 different datatypes as well. -- what gives?
This is only supposed to report the TYPE of the field,. Not automagically coerce the
field to some predefined format. Who decided what was and was not allowed anyway? When
I saw the first version of the code, I assumed it would be fixed later. We're still no
where near getting if fixed from what I see.
*sigh*
P.P.S. You managed to get the different flags this time (minus the blob flag I might
point out -- redundant or not, code expects this flag to be present). I think you all
have just not tested PHP3 against a robust enough app. I know for a fact that my
database manager would break with the current implementation. But it runs fine on
php2.0
P.P.P.S: What gives with the if():else; construct? No recursive descent parser? I
mean, if you're aiming for C structure it's a small matter to use the proper C grammer
which is available in BNF format for YACC and LEX. Right?
Please reply.
---------------------------------------------------------------------------
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=989&edit=2
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
