Let's burninate the SQL tag!

Question

The sql tag was discussed most recently in Is the [sql] tag useful for DBA.SE? (May 2015). Things have changed, and it is time to revisit this discussion.

---

The most popular views last time were that sql is not useful and should be removed.

The opposing (almost equally popular) view was:

The sql tag should be used when the question concerns the language itself. Complex queries and such. Still a common tag, but not noise.

At the time, query was a synonym to sql, but this has now been removed. Since we now have a separate tag for complex queries, this does not now justify keeping sql around.

The tag ansi-sql-standard has also been renamed to sql-standard, so questions about the SQL Standard itself have a good home.

In similar style, we could create a new tag for questions specifically about the SQL language, named sql-language. This would remove the last use of sql.

Note: It is essentially impossible to type "sql server" in the tags box (when writing a question) without ending up with sql, since the space completes the 'sql' tag. This is why so many SQL Server questions end up tagged "sql" without an apparent specific product.

---

Proposal

1. Create a new tag sql-language for questions about the SQL language
2. Start the process* to burninate and blacklist sql

Upvotes for this question will be taken to signify agreement; downvotes, disagreement.

Add an answer if you want to expand on your reasons for being in favour or opposed.

_{* Stack Overflow has a formal process, but we would likely have a follow-up discussion to decide the best approach.}

---

Follow-up posts here on dba.meta:

• Removing the SQL tag
• Please help us delete the SQL tag!

---

Related reading:

• Burninate [sql] on meta.SO (Dec 2017)
• What constitutes a SQL question? When to tag SQL and when to tag something else?
• when should the "SQL" tag be used? (Jan 2011)

Answer 1

I agree.

The sql tag is just too generic.

Having the following tags should be sufficient enough to tag questions correctly with whatever Structured Query Language Dialect/Programming Language is being used:

• sql-standard (ANSI)
• plsql (Oracle)
• t-sql (Microsoft SQL Server / SAP Sybase)
• plpgsql (PostgreSQL)

Answer 2

The sql tag has now been burninated.

It has also been blacklisted.

(technically, marked intrinsic, so inbound migrations are not blocked; the tag is removed during migration).

Thanks to everyone who participated in the discussion and clean-up effort.

Answer 3

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/pgsql, nor 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:

1. PostgreSQL:
   • 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.
2. Oracle:
   • 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.
3. DB2:
   • Supported routine programming languages
   • Internal
     • SQL Procedural Language (SQL PL)
     • PL/SQL support (yes, this is Oracle's PL/SQL language – kinda neat, actually)
   • External
     • External routines
     • C/C++, .NET CLR (very similar to SQLCLR), COBOL (yuck), Java, OLE, and OLE DB

4. MySQL:

   • The Using Stored Routines (Procedures and Functions) page states:

     MySQL follows the SQL:2003 syntax for stored routines, which is also used by IBM's DB2

   • The CREATE PROCEDURE and CREATE FUNCTION Syntax page indicates that the only language option is "SQL", hence this is essentially the "SQL / SQL PL" option of DB2.

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:

• postgresql
• postgresql plpgsql
• postgresql sql
• postgresql plpgsql sql
• postgresql function sql (a routine written in pure SQL)
• db2 stored-procedure .net (a routine written in a .NET language)
• db2 function sql (a routine written in SQL / SQL PL)
• oracle function java (a routine written in Java)

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?

Regarding sql-standard and sql-language tags

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 ;-).

Conclusion

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")

Answer 4

Against - SQL is not the only query language in existence. For OLAP we have MDX, for various NoSQL solutions we have different proprietary query languages. SQL and PL/SQL are not the same thing on Oracle.

For - Having said that, SQL is redundant on most questions it's used on.

Answer 5

For Burninantion.

I am still for burnination, but think the RDBMS tag is not sufficient and I certainly do not think all query-questions for PostgreSQL should be tagged pl/pgsql, nor pl for Oracle.

• In some RDBMs systems, like MySQL and Microsoft SQL Server, they confuse their declarative languages with their procedural language.

  • In Microsoft SQL, they call their stuff "T-SQL" and do all kinds of funky things, everywhere (such as permit you to call .NET stuff). For the Microsoft users, think of pl/pgsql like the CLR, except unlike the CLR it doesn't require .NET and the compiler comes free with the database.

  • MySQL is even more awkward, in the case of MySQL, they refer to two distinct constructs as being "SQL". So you loop over a query with SQL in a "Stored Program" that is declared with language SQL but that enables a different set of constructs not possibleanywhere else (like LEAVE, REPEAT and UNTIL, etc). From the docs,

    The LANGUAGE characteristic indicates the language in which the routine is written. The server ignores this characteristic; only SQL routines are supported.

• In other RDBMses the parlance demands you refer to the declarative language as "SQL" and the procedural language as "pl" or simply something that is not SQL. In PostgreSQL for example pl/pgsql is the PostgreSQL implementation of pl which you can use to write server side procedures, but it's not the best nor is it the fastest -- you can write procedures (and, functions) in any user-defined procedural language (including JavaScript, Perl, Python, PHP, C) etc.

So that raises the question of what to do, and why I am for burnination. If you're having a problem with a query I think we should break it own into sql verbs and burninante the sql tag simply because it's vague. This answer is inspired by the SQL standard,

SQL Data and Data-Change statements

• [sql-select] (select)
• [sql-insert] (insert)
• [sql-update] (update)
• [sql-delete] (delete)
• [sql-truncate] (truncate)
• [sql-merge] (merge)

Schema Definition and Manipulation Statements

• [sql-alter] (alter-table)
• [sql-create]
• [sql-drop] (drop-table)

The problem with [sql] is that you can always do better, and most of these tags we already have. Some of these tags are already broken down further such as [alter-table]. I'm not saying the above tags are perfect. In the case the community wants to subdivide [sql-alter], I think that's a huge improvement further. We could provide sql-alter-x such that x can be (table, routine, type, transform, sequence). Before we dismiss this as being pedantic, moving from one database to another is a huge problem where even the experienced face novice questions and this kind of tagging system would be a huge improvement. It also makes it much easier to find dupes.

I can see two questions emerging from this proposal,

• What if the question has an INSERT and a SELECT?

  Use both [sql-insert], and [sql-select] (which will only require one more tag), or just use the outter-most verb [sql-insert]. Either way, this is an improvement.

• What if the user doesn't know which tag to use?

  This happens all the time anyway. Someone more experienced will have to take 5 seconds to work it out for them. Tagging questions is easy, and we have the tools to do this. I find this argument poor, but it seems likely someone will argue it.

---

In similar style, we could create a new tag for questions specifically about the SQL language, named sql-language. This would remove the last use of sql.

I want to be clear that on that point I don't think that suggestion accomplishes anything. I'm looking for more description in my tagging system [sql-language] is just a return to [sql]. Please don't do that. ;)

Answer 6

I think it would be useful to retain a tag for the language for those odd times when someone has a question about the standard, or some aspect of the language that works across many database-management-systems. An example question, where I've converted the sql tag to structured-query-language appears here.

In light of that, sql could perhaps remain as a synonym that points to structured-query-language

So, when someone types in sql as a tag, it would be replaced with structured-query-language, which would have one of two effects:

1. The poster would immediately see structured-query-language and realize that's not what they meant. At that point, hopefully they'll tag the question with sql-server instead. Here's my terrible mock-up of how the tag box would look if someone typed "sql", if it was a synonym of structured-query-language:

   

or

2. If the do have a question about the language, they'll appreciate the specificity of the fully-spelled-out version.

The cynic in me thinks we'll end up deleting the structured-query-language in 99% of the new questions tagged with it, but at least there should theoretically already be a sql-server tag on the question, eliminating the need to ask the perennial comment "do you really mean SQL Server?".

Answer 7

The tag oracle

All versions of Oracle database. Add a version-specific tag like oracle-11g-r2 if that context is important in the question. Do not use for Oracle products such as applications or middleware or other database products owned by Oracle, like MySQL or BerkeleyDB.

Is about identical to sql-server

All versions of Microsoft SQL Server (not MySQL). Please also add a version-specific tag like sql-server-2016 if that is relevant to the question.

Maybe instead of burning sql the correct option is to redirect to it as primary from sql-server