Bug #9491 Binding an integer or string buffer to a numeric column fails during fetch
Submitted: 30 Mar 2005 15:44 Modified: 3 Aug 2009 16:32
Reporter: Nathaniel Blanchard Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Server: Prepared statements Severity:S4 (Feature request)
Version:4.1 OS:Any (all)
Assigned to: Konstantin Osipov CPU Architecture:Any
Tags: C_API, PS

[30 Mar 2005 15:44] Nathaniel Blanchard
Description:
Some background:

We have an application that was written against MySQL 4.1 using the 4.1 client libs.  Knowning that some customers may try to run it against MySQL 5 when its released we decided to test it.  For the bulk of the application everything works fine.  However there is one issue we've found.  Now assuming that using the 4.1 client libs to connect to a 5.0 database (using only features that were available back in 4.1) is a supported path here is whats happening.

Bug:

Take a table that has a numeric column.  Using prepared queries, bind a buffer of type MYSQL_TYPE_LONG or MYSQL_TYPE_VAR_STRING to the numeric column output.  The call to mysql_stmt_bind_result will generate an error.  For instance:

Using unsupported buffer type: 246  (parameter: 5) 

Where 5 is the position of the numeric column in the query.  This works just fine connecting to a 4.1 database using the exact same application.

How to repeat:
Try to bind an output buffer of a type other then numeric to a numeric column and it will fail.
[5 Apr 2005 3:17] MySQL Verification Team
Could you please provide a test case of the code you are using ?.

Thanks in advance.
[7 Apr 2005 19:48] Nathaniel Blanchard
I found the problem looking at the MySQL source code.  In 5.0, there is a new column type defined as MYSQL_TYPE_NEWDECIMAL=246.  Obviously, the 4.1 client knows nothing about this column type.  So when a prepared query is executed against the 5.0 server, it returns the column as type 246, which the 4.1 client throws an error on because it doesn't know what to do with it.

I assume this is a lost cause trying to connect to 5.0 with a 4.1 application.  Is there any kind of compatibility mode setting our app could pass to the server upon connection to tell it to use the old 4.1 decimal column type?
[7 May 2005 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[31 May 2005 15:49] Jorge del Conde
Hi!

As you realized, this is not a bug.  You can find further information regarding the DECIMAL type and its implications of before & after 5.0.3:

http://dev.mysql.com/doc/mysql/en/numeric-type-overview.html

http://dev.mysql.com/doc/mysql/en/numeric-types.html

Thanks !
[3 Oct 2005 12:25] Alexey Stroganov
Due to fact that  4.1 client library does not support MYSQL_TYPE_NEWDECIMAL 
added in 5.0, and there is no way to disable new DECIMAL type on server side the 
only possible solution to avoid reported problem will be relink application that 
uses PS C API with the client library from 5.0 server distribution.  This fact should 
be noted in Upgrade section in our manual.

As it was discussed it is also possible to fix 4.1 client libraries to support 
new DECIMAL type, so when this will be fixed it will be possible/enough 
to link application with 4.1 client library to communicate with 5.0 server 
in case of using of PS C API.

I changed status of this bug on 'Verified' and severity on 'Feature request'.
[3 Oct 2005 23:17] Konstantin Osipov
For a short test case see Bug#13655
[3 Aug 2009 16:32] Konstantin Osipov
This bug is specific to 4.1 client library, which is unaware of 5.0 new column type MYSQL_TYPE_NEWDECIMAL.
It was relevant to update 4.1 client library back in 2005. Now, when the default in all distributions is 5.0 or 5.1, this no longer makes sense.