[11.5.362 Pro] - $CURRENT(...)$ issues on MariaDB

[11.5.362 Pro] - $CURRENT(...)$ issues on MariaDB

I've got a snippet with the following code:

	Code:
	`$CURRENT(param1, names_only, skip_parentheses)$`

It fails when it comes to delimited user-defined variables.
Applying that snippet to a variable

	Code:
	@user_defined_variable

makes it become

	Code:
	`@user_defined_variable`

instead of

	Code:
	@`user_defined_variable`

It seems that the $CURRENT(...)$ macro considers the '@' as part of the name, which it isn't. It's just a marker that makes that name a user-defined variable (https://mariadb.com/kb/en/user-defined-variables/).

$CURRENT$ macro isn't database aware. It 's kind of generic text processing macro. Depending on its parameters, it can return current word, current text surrounded by qualifiers like ` ` or [ ] or " " if found around the current word, current selection, or the entire line.

For this kind of usage, you would need a more complex macro like the following

	Code:
	$$ SELECT CONCAT(CASE WHEN '$CURRENT(param1, names_only, skip_parentheses)$' LIKE '@%' THEN REPLACE('$CURRENT(param1, names_only, skip_parentheses)$', '@', '@`') ELSE '`$CURRENT(param1, names_only, skip_parentheses)$' END, '`') $$

I didn't know it wasn't database aware. The example you provided will work in that simple case but if I had to switch every occurrence of the $CURRENT()$ macro that might meet delimited user-defined variable in MariaDB, that would create a snippet maintenance nightmare.

Though it would work if user-defined macros or nested snippets were possible. But I guess that would be extremely difficult to implement. You don't happen to have something similar planned on your roadmap, do you?