ID: 989
Updated by: jimw
Old-Status: Open
Status: Closed
Bug Type: Feature/Change Request
Assigned To: 

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";
                case FIELD_TYPE_TINY:
                case FIELD_TYPE_SHORT:
                case FIELD_TYPE_LONG:
                case FIELD_TYPE_LONGLONG:
                case FIELD_TYPE_INT24:
                        return "int";
                case FIELD_TYPE_FLOAT:
                case FIELD_TYPE_DOUBLE:
                case FIELD_TYPE_DECIMAL:
                        return "real";
                case FIELD_TYPE_TIMESTAMP:
                        return "timestamp";
                case FIELD_TYPE_DATE:
                        return "date";
                case FIELD_TYPE_TIME:
                        return "time";
                case FIELD_TYPE_DATETIME:
                        return "datetime";
                case FIELD_TYPE_TINY_BLOB:
                case FIELD_TYPE_MEDIUM_BLOB:
                case FIELD_TYPE_LONG_BLOB:
                case FIELD_TYPE_BLOB:
                        return "blob";
                case FIELD_TYPE_NULL:
                        return "null";
                        return "unknown";


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.


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 

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

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to