1 - If your intent is to write a piece about SQL that you feel may be relevant across dialects, then you are quite right to not include any specific dialect in the headline.
2 - However, if you're only going to use examples from your knowledge of just one dialect, then please, do clearly state that somewhere in the opening paragraph.
Re the first of those: alas when most of us scan articles to read, we are likely to skip past ones that mention a dialect that we don't know or use. However that would be a poor reason for us to be skipping a piece that possibly has wider applications. So this is a reason to not mention the dialect in the headline.
Re the second: conversely, if we start reading an article apparently about "SQL" and encounter something that simply isn't true for the SQL dialect that we know and use, then we're likely to be annoyed and maybe stop reading(*).
The reality is that there are so many SQL dialects, and they vary so much, that we can't expect to avoid these effects. Few of us are likely to know more than a handful of dialects well, but many of us will probably know specific ones disturbingly well.
Data can be an unforgiving area in which to work with dialect misundertandings being equally terrible when they cause rows of data to either:
- multiply noticeably on the scale of millions;
- become rare exceptions that go unnoticed.
My hope is that if you are open about your context - and also invite cross-dialect supplementary comments - then we can all benefit from shared insights.
For what it's worth, my reality is that I have to do this in reverse. In working life I only use the products supplied to me by my employer. However I am interested in the variations and possibilities of others - other people, other products, other platforms. That requires me to have to push through the psychology and annoyances that I've mentioned above to keep broadening my knowledge - but it would be nice if that took less conscious effort.
I hope you found this post useful and apologise if you did not.
- (*) Actually, there's a subtlety there: as almost no SQL product uses "the standard" in full, we all get misled about what is normal for SQL. The harsh truth is that there is no normal at all. If I put my programmer hat on then I can't think of any other language in which the variations from the standard seem to outweigh the conformity to it.
Level up every day