Re: Re: artificial constraints in php_mysql_get_field_name

Hi Zeev, thanks for the prompt reply. I don't think another function is necessary if this gets changed in 4.1. what do you think? could you add this to the 4.1 TODO list? At 23:36 7/18/2001, Zeev Suraski wrote the following: -------------------------------------------------------------- >No good reason for that. When I wanted to change that, it was already too late in the game. >It'd probably make good sense to add a mysql_get_field_name_ex() which returns a more >accurate value. > >Zeev > >At 00:37 19/07/2001, Cynic wrote: >>Hi there, >> >>could anyone tell me what is the reasoning behind the constraints >>on the values returned by php_mysql_get_field_name()? I. e.: >> >>... >>1737 case FIELD_TYPE_SHORT: >>1738 case FIELD_TYPE_LONG: >>1739 case FIELD_TYPE_LONGLONG: >>1740 case FIELD_TYPE_INT24: >>1741 return "int"; >>1742 break; >>1743 case FIELD_TYPE_FLOAT: >>1744 case FIELD_TYPE_DOUBLE: >>1745 case FIELD_TYPE_DECIMAL: >>1746 return "real"; >>1747 break; >>... >> >>why doesn't it return "short", "longlong", "double" etc. >>i. e. the >>real value? >> >>This has been so since php_mysql.c v1.1 (2yrs, Zeev), so there must be >>a good reason behind this, but I just see it. anyone care to enlighten >>me? cynic@mail.cz ------------- And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7