Re: Re: artificial constraints in php_mysql_get_field_name

I think it would have a much broader effect. I used this function when I wrote a generic database interface years ago, so my guess is that quite a few people have used it since then as well. At 01:25 19/07/2001, Cynic wrote:

Well, were talking about a pretty specialized function, probably used only in programs like phpMyAdmin etc. On the other hand, software like phpMyAdmin needs real info, so... Looks like the constraint makes the function pretty useless: you'll get far more useful info from "show columns from table" today. Anyway, you could prolly get an idea how much welcome (or not) this change would be if you asked in php-general@. I could do it if you're interested. At 23:56 7/18/2001, Zeev Suraski wrote the following: -------------------------------------------------------------- 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/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net ------end of quote------ 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/