php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #989 Incomplete date type reporting
Submitted: 1998-12-14 14:42 UTC Modified: 2001-02-10 12:38 UTC
From: shamim_islam at hotmail dot com Assigned:
Status: Closed Package: Feature/Change Request
PHP Version: 3.0.5 OS: N/A
Private report: No CVE-ID: None
 [1998-12-14 14:42 UTC] shamim_islam at hotmail dot com
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-12-13 15:44 UTC] joey at cvs dot php dot net
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?
 [2000-07-19 09:48 UTC] hholzgra at cvs dot php dot net
changed type to feature request
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 26 09:01:29 2024 UTC