I am both for and against this proposal, so ±1 🙃
For / 👍 / Agree / 😺
Yes, the sql tag by itself is currently quite ambiguous. And not just because it's what you get as you try to type in "sql" space "server", but I would expect also due to it being how many folks, whether right or wrong, refer to Microsoft SQL Server. This is why I have often changed the sql tag on a question to be either t-sql and/or sql-server (both here on DBA.SE and also on S.O., and of course, when the question concerned MS SQL Server). So yes, its current usage makes it rather meaningless.
Against / 👎 / Disagree / 😾
I completely agree with @EvanCarroll regarding his statement of:
I certainly do not think all query-questions for PostgreSQL should be tagged
pl for Oracle.
Microsoft SQL Server does not really have a separation of language types to distinguish between the database interaction statements (DDL, DCL, DML, etc) and the programmatic constructs. It is just all Transact-SQL. SQLCLR doesn't really count here as a separate language because when you interact with SQL Server via SQLCLR, you still have access to all (or most) that T-SQL offers. However, it seems that the other RDBMSes (at least the ones we are concerned with here) do have a formal separation:
- Chapter 38. Procedural Languages
- SQL, PL/pgSQL, PL/Tcl, PL/Perl, and PL/Python (these come with PostgreSQL but there are independent projects that have extended the number of procedural languages)
- Example showing that SQL and PL/pgSQL are not the same thing. Routines can be written in pure SQL, but I believe that is fairly uncommon given that I seem to recall that those don't get fully optimized. Either way, a question regarding queries in PostgreSQL need more than a postgresql tag, but also should not be forced to use a plpgsql tag as that doesn't accurately reflect the subject of the question.
- Chapter 24. SQL, PL/SQL, and Java
- SQL, PL/SQL, and Java
- Just like with PostgreSQL, SQL is how one interacts with the data and data structures, but routines (which may or may not include SQL) are written in PL/SQL or Java.
In each of the above cases, the RDBMS tag by itself isn't about queries (or not necessarily so) as it could be about configuration, administration, etc. And questions that are about queries should have a tag to further specify (such as backups would do in combination with any of the RDBMS tags). But questions about the procedural language are not necessarily about the query(ies) in the routine. Hence the following tag combinations are all valid:
SO, I think we do kinda need to keep the sql tag around, but perhaps provide guidance, if possible. Yes, we will still have to do maintenance / cleanup from time to time, but I don't see us eliminating that by getting rid of the sql tag entirely since I'm not sure how likely it is that people would correctly pick the query merely to indicate that it was the language chosen for the routine when they chose
SQL as the language. And for those looking at the definition of the query tag, it seems specific to
SELECT statements (i.e. getting data) which still leaves a lot of ground to cover.
In other words, if the tag combination of sql-server + t-sql is validly distinct from sql-server + t-sql + query (or even just sql-server + query), then wouldn't we need postgresql + yadda-yadda-yadda to be distinct from postgresql + query? And wouldn't it be natural for said tag to be sql?
How often do we have questions that are about the language itself that are not RDBMS-specific and not about the ANSI standard? I would think that we could get away with just one of these tags. Of course, for those times when we do have questions about SQL in a generic, non-RDBMS-specific, non-ANSI standard sense, then a sql tag by itself would accurately denote that ;-).
While the frustration surrounding the current use (or more accurately, misuse) of the "sql" tag is understandable, I don't believe full burnination is in this sites best interest.
I do see that the current tag definition for sql does state that it is for the language and not for Microsoft SQL Server, and I'm sure that very few folks ever read that. I'm not exactly sure what should be done outside of a concerted group effort to remove that tag from questions where it is not correctly applied. I have no idea what the possible options / courses of action are to better enforce proper usage. It just seems that rather than reducing confusion overall, removing it entirely will simply shift the confusion to a different area.
(so now that I got all of this out, I suppose I am more "against" than I am "for")
[insert]the current tag being a synonym to it. I'm not sure what the principle is if we're invoking
sql-language. I actually think that would make it worse.
syntaxis actually more vague, as it would include questions about non-SQL query languages too (like
[sql-language]alternative sounds redundant IMO ("Structured Query Language - Language"). I think we should look for a better option, tough I can't find a good suggestion right now.
[sql]tag should be either burninated or adapted because it currently involves (most of the time) needless work and does not add much value.
SQLis a useful tag since it's distinct from clustering/replication/security/tuning/etc./etc. Or, if it is used in conjunction with these then at least you would know just from the tags that the question was related to database scripting in some way...
[sql]tag involves superfluous work most of the time.