Re: artificial constraints in php_mysql_get_field_name

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? TIA 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

-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/