The 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 is not useful and should be removed.

The opposing (almost equally popular) view was:

The 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, was a synonym to , but this has now been removed. Since we now have a separate tag for complex queries, this does not now justify keeping around.

The tag has also been renamed to , 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 . This would remove the last use of .

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


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

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:

Related reading:

  • What do you see as being the correct tag for this question instead of 'sql', should it be 'sql-language', or neither? Commented Aug 28, 2018 at 10:16
  • @JackDouglas Well there's also syntax 🙂 but I guess sql-language would be OK. I would also be happy with neither. A fresh start for sql-language would give us a chance to settle on good usage guidance and discuss its usage/usefulness. (I am not hoping to solve all known tagging problems in this area with this change).
    – Paul White Mod
    Commented Aug 28, 2018 at 10:25
  • 1
    I should have said I've already upvoted and think we should get rid of 'sql' too — but we probably need some sort of rough idea of what 'Start the process to burninate' involves in terms of re/detagging the 10k 'sql' questions. Do we initially rename the tag to 'sql-language' and work from there? Commented Aug 28, 2018 at 10:35
  • 1
    @JackDouglas If we get common agreement on the idea above in principle, I would expect to follow up with a question about how best to go about doing it. It might be easiest to simply remove sql and start from fresh, but that would require a Community Manager. Renaming would make it hard for sql-language to get a fresh start. Added a note to the question body to cover this.
    – Paul White Mod
    Commented Aug 28, 2018 at 10:39
  • @JackDouglas [sql-insert] with [insert] the current tag being a synonym to it. I'm not sure what the principle is if we're invoking syntax and sql-language. I actually think that would make it worse. syntax is actually more vague, as it would include questions about non-SQL query languages too (like cypher) Commented Aug 29, 2018 at 10:38
  • The [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.
    – MDCCL
    Commented Sep 6, 2018 at 17:17
  • @MDCCL Ah you mean RAS syndrome, well yes it isn't perfect - and better suggestions are welcome. If we agree to get rid of sql here, we will go on to discuss the specifics in a separate question.
    – Paul White Mod
    Commented Sep 6, 2018 at 17:21
  • 1
    Yes, I mean the RAS syndrome (didn't know of it, thanks for the link). Yes, it's more convenient to discuss the specifics in a separate question, but I think the [sql] tag should be either burninated or adapted because it currently involves (most of the time) needless work and does not add much value.
    – MDCCL
    Commented Sep 6, 2018 at 17:35
  • 1
    SQL is a very generalized topic in the world 'database administration domain'. As usage of dba.se expands, and more aspects of the DBA world are represented on this site i think that SQL is 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...
    – Zach Smith
    Commented Sep 13, 2018 at 7:12
  • is there a way to prevent it being used on it's own?
    – Zach Smith
    Commented Sep 13, 2018 at 7:13
  • @ZachSmith No there isn't.
    – Paul White Mod
    Commented Sep 13, 2018 at 8:55
  • I'm not clear on what we're trying to accomplish. I think people use "sql" to indicate they are asking a syntax question, and then add an additional tag to indicate what RDBMS system they are using. If we are trying to prevent people from using "sql" when they mean "mssql" then convert it to "sql-syntax"? OTOH, most questions tagged "sql" are of poor quality. I just filter out the RDBMS' I don't know, so when I did a search on "sql" the results were highly limited.
    – rottengeek
    Commented Sep 26, 2018 at 14:17
  • @rottengeek The basic proposition here is that the [sql] tag is useless and we ought to get rid of it. There are other, related and not-so-related issues at the same time, but the uselessness of the current tag is the primary focus.
    – Paul White Mod
    Commented Sep 26, 2018 at 14:23
  • 1
    @JosephDoggie - do yourself, and the others at your workplace, a favor, and start calling it "SQL Server". Precision is important.
    – Hannah Vernon Mod
    Commented Sep 27, 2018 at 15:11
  • 3
    @JosephDoggie Yes, that's a problem in other areas of the world too, but the fact is that (a) the database sub-language called SQL, (b) the database management system called SQL Server, (c) the set of administration tools called SQL Server Management Studio, and (d) the dialect called Transact-SQL —which is also used in Sybase/SAP ASE— are (e) four different things. Also, here in DBA.SE the [sql] tag involves superfluous work most of the time.
    – MDCCL
    Commented Sep 27, 2018 at 15:13

7 Answers 7


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:

  • 20
    And "wtf-sql" for mysql?
    – gbn
    Commented Aug 28, 2018 at 9:52
  • 1
    Couldn't find the dialect (name) for MySQL. I guess it's just mysql-sql.
    – John K. N.
    Commented Aug 28, 2018 at 9:55
  • 10
    I think there is a major confusion here. pl and pl/pgsql are not "sql". I know Microsoft and MySQL confuses this, but not PostgreSQL and Oracle. SQL is not a Procedural language. PL was invented for when a declarative language wasn't sufficient. You can't write a query in pl/pgsql. You can only write the query in SQL. You can't loop over a query in sql, you can only loop over the query in pl/pgsql. Commented Aug 29, 2018 at 4:39
  • @hot2use I suggest to make the mysql into a different meta question. Fortunately, the community seems to agree the proposition, injecting new problems into the discussion may harm this agreement. It is a dangerous thing in meta discussions, an agreement is fortunately reached, I suggest to try to preserve it.
    – peterh
    Commented Aug 30, 2018 at 16:14
  • 3
    plsql for Oracle or plpgsql for Postgres is plain wrong. That would only apply to questions regarding stored procedures or function. Not plain SQL query functions. Those two DBMS (unlike e.g. SQL Server) make a strong distinction between SQL (queries, DML) add procedural code (PL/SQL, PL/pgSQL)
    – user1822
    Commented Sep 7, 2018 at 11:31
  • 1
    I agree with @a_horse_with_no_name and have been trying to make that point in my answer. PL/SQL and PL/pgSQL don't simply mean "stored routines", but are specific languages for doing such things. Using SQL commands to create a table space in Oracle isn't PL/SQL, it's SQL. And a PL/SQL (or PL/pgSQL in PostgreSQL) procedure or function might not contain any SQL. You can also create a Java procedure or function in Oracle, which isn't PL/SQL. These might be the most common languages for such things, but we don't use C# to mean .NET as one could use VB.NET, F#, VC++, etc as the .NET / CLR lang. Commented Sep 7, 2018 at 20:27

The 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.


I am both for and against this proposal, so ±1   🙃

For / 👍 / Agree / 😺

Yes, the 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 tag on a question to be either and/or (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 tag, but also should not be forced to use a 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:
  4. MySQL:

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 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 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 tag entirely since I'm not sure how likely it is that people would correctly pick the 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 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 + is validly distinct from + + (or even just + ), then wouldn't we need + to be distinct from + ? And wouldn't it be natural for said tag to be ?

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

  • 1
    The basic idea is that [sql] is just too vague and overused to be useful. When was the last time you found anything useful by searching for that tag? Now imagine a world where [sql] did not exist. Sure, we could have some interesting discussions around exactly how best to tag questions asking how to write a query, or use a specific language feature, but that's not the discussion we are having here. What deleting this tag would do is give us a chance to refresh, without an ambiguous tag that is currently attached to 10,042 questions (out of 69,342 total).
    – Paul White Mod
    Commented Sep 7, 2018 at 14:37
  • 1
    So a couple of questions you might like to ponder. 1 Would life be better or worse without the [sql] tag - assuming no other changes. 2 Which tags do you feel are missing or currently misnamed, that would help you find questions you can answer, or answers you want to read?
    – Paul White Mod
    Commented Sep 7, 2018 at 14:44
  • @PaulWhite I hear ya. I get the frustration with the current state of things and the intent of this proposal. Still, I feel that the issue has, so far, been approached from a very SQL Server-centric view of the world. I suspect that this pain is felt most strongly by the SQL Server community, which is the same group that would be the least impacted by removing (rather than fixing the usage of) the [sql] tag. I don't think I'm the right person to answer the questions you posed in the first comment because I primarily work with SQL Server, and so the [sql] tag has little meaning to me, and ... Commented Sep 7, 2018 at 20:06
  • a world without it would simply mean less opportunity to update tags on SQL Server questions 😉. But, I don't think that the non-SQL Server communities would be best served by removing it. The tag certainly has plenty of meaning from most other RDBMSes, and it is not their fault that it got so misused here. I don't see taking it away as an improvement because it leaves a void that would naturally be filled by re-adding a [sql] tag. My life is mostly unaffected without it, but I think it would be worse for those not using SQL Server when their question is specifically about SQL and not PL, etc. Commented Sep 7, 2018 at 20:14
  • Ok well thanks for writing the counter-argument, even if I don't really understand it. I guess I'll wait for one of the non-(SQL Server) people to clarify how the [sql] tag is useful and ought to be retained unchanged.
    – Paul White Mod
    Commented Sep 7, 2018 at 20:39
  • @PaulWhite No problem. I was truly more 50/50 until I did the research on the various RDBMSes. Could it be that this question is not getting much participation by non-SQL Server folks? And if so, is there a way to rope them in so as to get the perspective of (ideally) someone from each of those communities? Commented Sep 7, 2018 at 20:50
  • 1
    How could we know? I've promoted the question in our main chat rooms and [featured] it on meta and main, what else to do? It'll be around for a month or more so there is time. Evan will be pleased you regard him as a SQL Server person 🙂 Not to mention horse, MDCCL, and Jack Douglas.
    – Paul White Mod
    Commented Sep 7, 2018 at 20:51
  • Does it matter if it's postgresql+plpgsql or postgresql+sql tags? postgresql is by far the most useful here (or pgsql).
    – gbn
    Commented Sep 12, 2018 at 10:08

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.

  • 1
    Are you for or against? 🙂 If for, how do you feel sql adds value? Or, what tag should replace it? I guess I'm asking if you can expand your answer to make the point clearer.
    – Paul White Mod
    Commented Sep 10, 2018 at 10:59
  • 1
    Against burninating the tag in theory, as there are certainly DBMS platforms that don't use SQL, and ones (Oracle for example), where the SQL interpreter embedded in PL/SQL is different from the one you get if you just run a SQL query. In practice, SQL is redundant 99+% of the time. Sitting on the fence about this. Can you set it so it produces a warning to only use SQL if you somehow need to differentiate it? Commented Sep 10, 2018 at 11:06
  • 1
    No we don't have a tool for that. I'm thinking we can come up with a better name for a tag for questions about the SQL language itself, and actively police it so it doesn't get waaaaaay out of control like sql did. Separate discussion though.
    – Paul White Mod
    Commented Sep 10, 2018 at 11:09

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

Schema Definition and Manipulation Statements

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

  • 2
    I am kinda lukewarm about sql-language myself; though it would address the one remaining concern about burninating sql, so to that extent, I support it. As a fresh tag, it would either gain acceptance and widespread usage, or would not. I rather suspect it would not, since sql was only really super-popular due to the "SQL Server" issue, and the now-defunct synonym with query. I don't see any value in prefixing existing tags of dubious value with sql-. Anyway, that's a side-discussion, like we had for function-aggregate.
    – Paul White Mod
    Commented Aug 29, 2018 at 11:17
  • 3
    A tagging system needs to be usable. This proposal is unusable, unfriendly, too puritanical, and frankly who cares about such preciseness?
    – gbn
    Commented Sep 3, 2018 at 13:27
  • 3
    @gbn I don't understand what any of those opinions is rooted in. Who cares about such preciseness? The thousands of people that are currently using the tags. Commented Sep 3, 2018 at 14:42
  • 2
    They look for "sql" and be done with it. We can sharpen that (this whole discussion) but your proposal won't be used: too complex, unfriendly
    – gbn
    Commented Sep 4, 2018 at 6:52
  • 3
    Right, so they'll look for SQL (because they want to tag and they care), and they'll presented with tag-options that are useful because they'll show up when they're all prefixed with sql-. Again, we have all these tags now. Commented Sep 4, 2018 at 6:57
  • 1
    Then remove the clutter and stick with vendor SQL tags.
    – gbn
    Commented Sep 4, 2018 at 10:35

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 tag to appears here.

In light of that, could perhaps remain as a synonym that points to

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

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

    enter image description here


  1. 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 in 99% of the new questions tagged with it, but at least there should theoretically already be a tag on the question, eliminating the need to ask the perennial comment "do you really mean SQL Server?".

  • Creating structured-query-language unilaterally seems a bit bold, given the ongoing discussion. I didn't create sql-language partly to discourage a sudden proliferation of new tags in this area before the discussion was over, and a conclusion reached. Perhaps there is some advantage to actually creating the tag over simply mentioning it in your answer that I have not yet grasped?
    – Paul White Mod
    Commented Sep 11, 2018 at 19:48
  • well, it's easy enough to kill off. It's not affecting anything at the moment, other than that one question. I'm watching the new tag, and will delete it if we decide it doesn't need to be there, or is unhelpful. Having it around makes it a bit more obvious what the benefit might be, and how it might look. I'm a visual person so it makes it easier for me to understand if I see something in action.
    – Hannah Vernon Mod
    Commented Sep 11, 2018 at 19:49
  • 1
    I don't hate this idea by the way, though I do wonder how much of an improvement it is.
    – Paul White Mod
    Commented Sep 11, 2018 at 19:59
  • 3
    I bet 90+% of new contributors using SQL Server will just type SQL and end up with a question tagged [structured-query-language] and not look at it again. Just more mess for us to clean up. Commented Sep 12, 2018 at 7:14
  • 1
    I'm not against [structured-query-language] per se but 99.9+% of users aren't going to think of typing that as a tag so that's a huge strike against it, IMHO. of course we can have the tag and retroactively add it to questions but, again, just more work. And potentially 50+% of questions can have the tag. It's that last stat that makes it clear to me that a new tag for any SQL questions is unnecessary. If we add any new tags they should be for very specific types of SQL queries, IMHO. And I mean functional things like the "gaps and islands" tags we have already. Commented Sep 12, 2018 at 7:17
  • 3
    Personally I have doubts about the utility of any tag for the language of SQL. This answer is really just to flush out the possible surface-area of the problem with sql.
    – Hannah Vernon Mod
    Commented Sep 12, 2018 at 12:31

The tag

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

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 the correct option is to redirect to it as primary from

  • 5
    sql is the language of SQL, or Structured Query Language. We'd like to get rid of the sql tag since it seems to be confused the vast majority of the time with sql-server tag. It seems you're making that same confusion.
    – Hannah Vernon Mod
    Commented Sep 11, 2018 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .