My personal opinion (not the one of my employer): I fully agree with you, Pat.

SQL-99 is way outdated. SQL-2007 is the current standard, which systems should measure against.

Mimer is not really a serious competitor in the DBMS market, is it? And I stand by my opinion that even Mimer cannot claim full support for any SQL standard either simply because of some bugs in the standard. Some guys at my University run the BNF for the SQL syntax through a tool and noticed that some non-terminal symbols were not defined at all, some others had circular dependencies. So that could never have worked and no one could build a system for this. (Alas, I don't recall whether they used SQL-99 or SQL-2003.)

That's wholly unrealistic though. There has to be an acceptable lag. There's no point measuring RDBMSs vendors against standards they can never hope to satisfy in the time frames.

pootle flump ur codings are working excelent.

The real benchmark to my mind is does it genuinely meet the standard they claim.

I don't know what development cycle db vendors are on, but even if they have representatives on the standards council it can take a while to get the product in line with a newly introduced standard. I'd expect most vendors to be 2..3 years behind the relevant ISO standard.

I'd expect more. The major RDBMSs have major releases of about 3+ year cycles. I would measure today's products against 2003. 2007 is not a fair measure.

pootle flump ur codings are working excelent.

As Knut observed, there are political issues at work within the ISO that have produced specifications for SQL that are impossible to implement according to the published specification.

As far as I know, the last formal specification by ISO for the SQL langauge that can actually be implemented (BNF converted to executable code) is the SQL-99 specification as it was revised in 2001. In my mind, a standard that can't be implemented is a waste of time and paper (or PDF as the case might be). If that is correct, then the SQL-99 standard is the most current standard which can be implemented, and it is the standard that I think Mimer implements.

When discussing standards, one thing that we need to keep in mind is the percentage of the population that different SQL implementations reach. Since end users don't see or think about SQL syntax, the number of developers using an implementation is all that is really important in terms of standards application. That puts MySQL in the lead for distribution of a working standard, even though I think that it falls short in a number of really critical areas.

One real problem that I see with the ISO standard process is that it produces many variations of a given standard as that standard is revised and republished. A problem that I see in the real world is that few if any of the vendors have any incentive to implement those standards, which is further aggrivated by the cost of "following the bouncing ball" of an evolving standard.

Unless someone (probably the ISO itself) decides to make some hard choices, I see anarchy returning under the banner of standards. Someone needs to rein in the politically powerful groups within the standards body, and force them to only publish a standard that they can actually implement. Once an implementable standard is published, previous standards need to somehow "sunset" so that there is a fixed, predictable, yet attainable deadline for keeping up with the current standard. After those changes in the standards process are implemented, someone with the ability to enforce standards adherance needs to hold vendors accountable to the standard, and needs to call them out when they advertise compliance that they don't deliver... In today's international economy that job will probably fall to us, the "experts" in the field who are also ultimately the consumers of the products that are affected by the standards.

Standards are by nature a messy but important business. We all have a considerable investment in standards if we use more than one product/SQL engine, even if we don't explicitly see the investment that we've already made.

-PatP

No, it is actually a mixture of the standard lagging behind the products and the products also not having all the features of the standard. I think that is business as usual in a competitive market and you will see it everywhere. For example, we all know that there WLAN products that implement a pre-version of the respective standard.

The situation is that ISO standards are driven by the national standardization bodies like ANSI in the US or DIN in Germany. Those national standardization bodies are comprised primarily of two groups: (1) people employed by some vendor, or (2) univesities/research. The are very rarely others and the simple reason is that the ISO committee meets around the world in different places (typically very nice ones) and you have to get there and stay a few days - there are travel costs associated. The same applies to national committees. That all being said, if you are employed by some database vendor and if you also participate in ISO meetings, chances are that your employer covers those travel costs - and, of course, you try to work in favor of your employer in standardization questions. Thus, vendors typically implement a new feature in their product and once it is proven to work, it is attempted to include this feature in the standard if it is felt worthwhile. A very good example on that is a product called DataJoiner developed by IBM research. A couple years later you found it as SQL/MED (management of external data) in the SQL standard.

Now you take multiple competing vendors and you see that each product typically has (different) features that are not yet standardized, i.e. is ahead of the standard, and other standard features are not yet in the product (but in the product of a competitor). You will hardly find a feature in the standard that is in no product at all.

From a vendor's perspective, there are always resources constraints when developing the next version of a product - there are just that many people available. So implementing a feature just because it is in the standard and nice to have - but none of the users needs it, - has a hard time to make it through the plans. There is no difference in this respect between commercial vendors and open source vendors. (Besides, today there are virtually no real open-source-only vendors in the market anymore.)