Re: Re: artificial constraints in php_mysql_get_field_name

I think it'd break a huge amount of scripts, which is why I didn't even do it in the 3.0->4.0 move. Zeev At 00:55 19/07/2001, Cynic wrote:

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

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