[MDEV-32271] stored procedure invocation not checking underlying table structure alterations Created: 2023-09-27 Updated: 2023-10-12 Resolved: 2023-09-30 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Prepared Statements, Stored routines |
| Affects Version/s: | 10.4.31 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Rex Johnston | Assignee: | Unassigned |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | reprepare, stored_procedures | ||
| Description |
|
The second sp() call should probably fail with ER_WITH_COL_WRONG_LIST |
| Comments |
| Comment by Rex Johnston [ 2023-09-28 ] | ||||||||||||||||||||||||||||||||||
|
additionally prepared statements can too suffer from this
provokes no error. | ||||||||||||||||||||||||||||||||||
| Comment by Sergei Golubchik [ 2023-09-30 ] | ||||||||||||||||||||||||||||||||||
|
why would the second routine invocation or execute fail? you added a column the routine definition is still vaild. if you'd remove a column, it'd fail. | ||||||||||||||||||||||||||||||||||
| Comment by Rex Johnston [ 2023-09-30 ] | ||||||||||||||||||||||||||||||||||
|
then we should at least be consistent.
| ||||||||||||||||||||||||||||||||||
| Comment by Sergei Golubchik [ 2023-10-12 ] | ||||||||||||||||||||||||||||||||||
|
here is detects the ALTER TABLE and reprepares the statement using your original query text. that fails, because the query is no longer valid — WITH column list and SELECT field list have different column counts, indeed. I don't see this being the case in any other of your examples. |