Bug #2812 wrong value for stmt->field_count
Submitted: 15 Feb 2004 12:18 Modified: 25 Sep 2007 11:14
Reporter: Georg Richter Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Prepared statements Severity:S3 (Non-critical)
Version:5.x OS:Linux (Linux/Windows)
Assigned to: CPU Architecture:Any
Triage: Triaged: D2 (Serious) / R4 (High) / E4 (High)

[15 Feb 2004 12:18] Georg Richter
When executing SHOW VARIABLES in a prepeared statement stmt->field_count is 0 instead of 2.

How to repeat:
#include <mysql.h>
#include <stdio.h>

void main() {
	MYSQL		*mysql;
	MYSQL_STMT	*stmt;
	char		query[512];

	mysql = mysql_init(NULL);
	mysql_real_connect(mysql, "localhost", "root", "", "test", 0, NULL, 0);

	strcpy(query, "SELECT 1,2");
	stmt = mysql_prepare(mysql, query, strlen(query));

	/* stmt->field_count should be 2 */
	printf("Fields: %d\n", stmt->field_count);


	strcpy(query, "SHOW VARIABLES");
	stmt = mysql_prepare(mysql, query, strlen(query));

	/* stmt->field_count should be 2, but is 0 */
	printf("Fields: %d\n", stmt->field_count);


[17 Feb 2004 20:23] Miguel Solorzano
Tested against a server from BK tree 2 days older:

Fields: 0
Fields: 0
[18 Mar 2004 3:57] Konstantin Osipov
The reason of this bug is that we don't send types of columns in result set for SHOW and EXPLAIN commands.
However you should not use stmt members directly to obtain metadata information.
Statement is a black box and all work should be performed through API calls.
[18 Mar 2004 5:01] Alexey Botchkov
To solve this properly we should:
1. Separate parts of the mysql_show_***() forming field's lists.
2. Call these in send_prepare_results()
3. Since we are going to modify all the show's it worth to make
     them handling 'WHERE'.

<hf> monty, serg: I checked 2812. This one would be an decent WL item. We need to completely change the way we handle 'SHOW' commands. And it's close to the WL#173, and 'WHERE for SHOW' task. I'd propose put this bug to 'deferred' and fix along with that tasks.
<monty> hf: ok
[22 Mar 2004 10:22] Konstantin Osipov
Alexey, I just want to easily track all existing bugs in prepared statements.
[8 Aug 2007 11:39] Konstantin Osipov
Bug #29901 result of prepared statement changes between 2 executions was tagged a duplicate of this bug.