| Bug #2261 | Can't use @user_variable as FETCH target in stored procedure | ||
|---|---|---|---|
| Submitted: | 2 Jan 2004 15:37 | Modified: | 23 Sep 18:30 |
| Reporter: | Peter Gulutzan | ||
| Status: | Verified | ||
| Category: | Server: General | Severity: | S3 (Non-critical) |
| Version: | 5.0.0 | OS: | Linux (SuSE 8.2) |
| Assigned to: | Target Version: | ||
| Triage: | Triaged: D3 (Medium) | ||
[2 Jan 2004 15:37]
Peter Gulutzan
[15 Jan 2004 2:29]
Per-Erik Martin
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.mysql.com/documentation/ and the instructions on how to report a bug at http://bugs.mysql.com/how-to-report.php Additional info: This is a deliberate limitation. Since the current cursor implementation in stored procedures is a "quick-and-dirty" temporary solution until we have the real cursors, it was deemed not be worth the time to do fetch into global variables.
[23 Sep 18:30]
Peter Gulutzan
I am changing the status back to "Verified". It appears that there is no longer a justification (or a justifier) for a "Won't fix" status. No improvement of cursors has solved the matter to go away in the five years since the bug was reported. And, unless I have missed something hidden in the manual, this never became a documented limitation. And the earlier comment about "global" variables hints that there may have been misunderstanding, since this report specifically is about variables of the form '@user_variable', which are legal in an analogous context, for example "SELECT 5 INTO @user_variable;".
