[11.3.277 Pro] - Always Add Delimiters vs $COLUMNS$

[11.3.277 Pro] - Always Add Delimiters vs $COLUMNS$

Adding delimiters (eg. Auto Complete / Always Add Delimiters set to Always add brackets [ ] for SQL Server) interferes with the merging feature that can be used in snippets. For example, the snippet

	Code:
	DECLARE @_$COLUMNS(vertical,types)$;

when used with Always Add Delimiters disabled it will produce the code

	Code:
	DECLARE @_tid int, @_is_enabled bit, @_name varchar(100), @_tag varchar(100), @_source_name sysname, @_target_name sysname, @_rows_to_copy int, @_rows_to_remove int;

but enabling Always Add Delimiters will make it look like this

	Code:
	DECLARE @[_tid] int, @[_is_enabled] bit, @[_name] varchar(100), @[_tag] varchar(100), @[_source_name] sysname, @[_target_name] sysname, @[_rows_to_copy] int, @[_rows_to_remove] int;

Now, I imagine trying to hammering together the powerful enough heuristics that would make SA guess properly could easily end up in an early prototype of the Skynet or some other semi-sentient artificial intelligence. But perhaps adding another option to $COLUMN$ telling it that disregarding the current value for Always Add Delimiters just might be a good idea this time could work. It already has quite a few, one more wouldn't make a bug difference. Er... I mean big difference.

(I'm sorry for the language. Sleep deprivation can cause strange things to happen).

EDIT: also, the same happens to `` and $OBJECT$ macro in MariaDB so I guess that issue applies to most macros and database dialects.

As far as I can tell the described result is an unwanted side effect if not classified outright as a bug. Always add delimiters should not apply to macro variables. If delimiters are always required, in snippets they can be added using quoted prefixes and suffixes to specify that explicitly like in the following not practical example, and how it used to work in some earlier versions

DECLARE "@_["$COLUMNS"]"$;

I will raise that issue and ask for more details.

Thank you very much!