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.
>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

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 

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]

Reply via email to