Bug #23033 SQLProcedures does not return the database name in the resultset

Description:
QLProcedures does not populate the PROCEDURE_CAT column in the resultset from the call.  While rows are returned, the application has no way to determine which database they belong to.  It doesn't matter if you provide a catalog name in the call or not, the results are the same.

How to repeat:
1) execute SQLProcedures agains a mySQL server that has databases containing Stored Procedures
2) observe that the resultset does not list the catalog (database) that the SP belongs to

Suggested fix:
Return the database name in the PROCEDURE_CAT column.

Yes, it is currently hardcoded to always return an empty string for both catalog (PROCEDURE_CAT) and schema (PROCEDURE_SCHEM). But since a database is a schema in MySQL, that is what should be populated, not the catalog field.

Hi Jim,

Saw your reply.  Both PROCEDURE_CAT and PROCEDURE_SCHEM are null.  Based upon what you said, PROCEDURE_SCHEM should be poplulated.  

Thanks... Rick

Re-implementation of SQLProcedures using INFORMATION_SCHEMA

Attachment: bug23033.diff (application/octet-stream, text), 14.87 KiB.

The patch I just attached re-implements SQLProcedures() by using INFORMATION_SCHEMA.

My earlier note about schema == database isn't quite correct. While the server team is going forward with a plan for that to be true (see 'CREATE SCHEMA', etc, in recent releases), our existing connectors for JDBC and .NET, as well as the other ODBC catalog functions, use catalog == database. That's a mess that we'll leave for sorting out another day.

The fix for this has been pushed, and will be in the 3.51.15 release.

Thanks for the bug report.

A note has been added to the 3.51.15 changelog.