MDEV-38329: Named Parameters in Invocation of Stored Routines

[rajatmohan22]

MDEV-38329: Named Parameters in Invocation of Stored Routines

Description

This a draft PR begins implimentation of support for named parameters in stored routine invocation, for ex:

CALL proc(param3 => 10, param5 => 'foo');
SELECT func(param2 => 3.1415);

---

Current State

right now CALL arguments are parsed strictly as positional expressions -

• CALL → opt_sp_cparam_list → sp_cparams
• Each argument is parsed as expr
• Arguments are pushed into Lex->value_list
• Binding in sp_head::execute_procedure() is strictly positional

There is no syntax of argument names and no name-based resolution. This PR starts adding support for ident => expr syntax.

---

Current Commit (WIP)

Commit 1: Introduce CALL parameter structure

Adds a Call_param structure in LEX:
LEX_CSTRING name
Item *value
Adds List<Call_param> call_param_list

Clears call_param_list in call_statement_start()

No functional changes yet.
Parser and binding logic remain unchanged.

This commit prepares the LEX layer to store named arguments in addition to positional ones.

---

Planned Implementation Steps

The remaining work to follow in additional commits in this PR:

1. Extend grammar in sql/sql_yacc.yy to allow both expr and ident => expr inside routine argument lists.

2. Represent CALL arguments as structured entries instead of raw Item* only, e.g. { name, Item* } where name is empty for positional arguments.

3. Add a resolution step before calling sp_head::execute_procedure(thd, &args). This step will:

• Resolve named arguments using sp_pcontext / sp_variable
• Preserve positional arguments (positional first, then named)
• Apply default values for omitted parameters
• Error on unknown parameter names, duplicate parameters, and missing required parameters

4. Add MTR tests covering procedures, stored functions, mixed positional + named usage, and error cases.

---

Design Direction

Resolution will occur before invoking execute_procedure() so that the existing positional binding logic — adjust_formal_params_to_actual_params() and bind_input_param() — can remain largely unchanged.

---

This PR is opened as a draft for early feedback on approach before implementing grammar and resolution logic.

[CLAassistant]

All committers have signed the CLA.

[rajatmohan22]

@abarkov @gkodinov hello,

I’ve pushed the initial groundwork for MDEV-38329 (introducing the Call_param structure in LEX and wiring it into call_statement_start(), no functional changes yet).

I’m currently continuing to research the execution and binding flow carefully before moving to the next step. I’d really appreciate your feedback when you have a moment and your help in keeping tabs on this PR so I stay aligned with the intended direction.

Thank you very much.

[rajatmohan22]

the buildbot/amd64-ubuntu-2204-debug-ps test runs fine locally. Since this is still a draft PR and i am working on this continuously, I will proceed with the next stage of development - ie i want to populatw call_param_list and use it in procedure execution for real named-parameter semantics

so i will skip this one failing test for now. I will come back and fix it - tbh it seems flaky but I will have a look at it in a little later stage

[grooverdan]

Hi, nice start.

[grooverdan]

Hi @rajatmohan22,

Thanks for addressing the test changes. It does show up things like "should have failed with error ER_SP_UNDECLARED_VAR". I'm hoping you've seen mysql-test/mtr --record main.call_named_param will create a result file and this doesn't need to be hand crafted.

Don't worry about the innodb.skip_locked_nowait test failure, its not on you - and MDEV-38817 / #4684 is there to fix it.

While this is in draft you're welcome to rebase (-i interactive - dropping the merge commits) and squash these commits to single commit (with the MDEV listed in the commit title). Look at the level of detail in some of the other commits to include. For example this should describe that the syntax is identical to PostgreSQL, Oracle and Firebird.

This would be really useful to have for stored functions too, but up to you if you include that in this task or a subsequent one.

[rajatmohan22]

Hey @grooverdan,

Thank you sm for the feedback.

Just a quick question: would you rather I squash the commits now, while the draft is still open, or after all the features have been added? I'm fine with either way; I just want to make sure it works for you.

Thanks for also pointing out the mysql-test/mtr --record main.call_named_param flow. That helped a lot. Instead of making the result file by hand, I will regenerate it correctly to avoid problems with formatting.

Also thanks for clearing up innodb.skip_locked_nowait and MDEV-38817. That really makes me feel better.

It would be great to add this to stored functions. I agree that it would make the feature more complete. First, I'll focus on finishing this cleanly. Then, I'll work on adding support for stored functions as well, either in this PR if I can, or as a follow-up.

Thanks again for your help.