When you click the "Run Query" button your browser will submit (POST) the runQueryForm to this url: https://data.stackexchange.com/query/save/1/1825610 where the 1 is the site id and 1825610 is the unique id for this query.
The FORM has a couple of INPUTs and TEXTAREAs.
| name |
type |
function |
| title |
input |
the title of the query |
| description |
textarea |
the description of the query |
| sql |
textarea |
the provided SQL query |
| g-recaptcha-response |
textarea |
the solved re-captcha for anoymous users |
These values are send to the server as application/x-www-form-urlencoded payload.
When you use a Data Explorer 'parameter' by adding ##name_of_var## to your SQL query the client side code will add an INPUT with that name to the FORM. There is no logic in place to disallow already used names.
When a FORM is submitted with multiple INPUT or TEXTAREA elements with the same name, both values will be send.
So when this form gets submitted:
<form action="/save" method="POST">
<input name="sql" value="Foo"/>
<input name="sql" value="Bar"/>
<button type="submit">Submit</button>
</form>
the server will receive in the body of the HTTP request:
sql=Foo&sql=Bar
In SEDE there is no code server-side to handle this case. The ASP.NET MVC Framework is kind enough to put these values into the only string variable it has to bind to and does so by separating the values with a comma. So in code the sql variable now holds Foo,Bar.
In Are query parameters broken in SEDE I shared which names are better not used as SEDE Parameter names and share that (updated) list here:
title
description
sql
g_recaptcha_response
In the comments Tim Stone said these names where better prefixed to prevent collision with names users might dream up for their SEDE parameters. That is still a good idea after 6 to 8 weeks. Until that PR is created and merged, chose your SEDE Parameter names with care.
