What have you needed out of ANSI SQL that is a gap in its Turing Completeness? Totally serious. A great many things can be dismissed as not being Turing Complete, so please provide us with some examples of why this is bad in ANSI SQL.

I did not mean that ANSI SQL was bad. However, by not being turning complete it has fundamental limitations that limit it from expressing certain logic (as you might need to do in a stored procedure). This frequently means that you must use proprietary extensions to SQL (such as PL/SQL) to accomplish these tasks.

My interpretation of the parent post was that it was a response to a comment about vendor lock in. I was only trying to point out that it is not always possible to ensure compatibility between databases by writing strict ANSI SQL.

I'm sorry but I don't even know what you are talking about. Who cares if ANSI SQL is Turing complete?

It stores data just fine and is not vendor specific.

You care about Turing completeness if you are trying to express something that requires it (which is something that frequently needs to be done in stored procedures). Also, SQL is not a data storage engine it is a query language.

ANSI SQL is not vendor specific but it is just a standard not an implementation. As a result you have to rely on vendors to implement the language. Many vendors deviate from the standard. This means that you cannot just write ANSI SQL and expect it to work on all databases.

Aren't vendors finally starting to abandon their proprietary crap in favor of SQL/PSM?

Interesting, I didn't know about SQL/PSM. Although judging by this:

http://en.wikipedia.org/wiki/SQL#Procedural_extensions

It looks like a lot of vendors still only support propriatary extensions.