4 ms·

Which is not turing complete. You need database specific extensions to get that. Edit: Also, not all databases follow the standard very closely

prodigal_erik 15y ago
Aren't vendors finally starting to abandon their proprietary crap in favor of SQL/PSM?
- eeperson 15y ago
  Interesting, I didn't know about SQL/PSM. Although judging by this: http://en.wikipedia.org/wiki/SQL#Procedural_extensions http://en.wikipedia.org/wiki/SQL#Procedural_extensions It looks like a lot of vendors still only support propriatary extensions.
moheeb 15y ago
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.
- eeperson 15y ago
  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.
badmonkey0001 15y ago
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.
- eeperson 15y ago
  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.

prodigal_erik 15y ago

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

eeperson 15y ago
Interesting, I didn't know about SQL/PSM. Although judging by this: http://en.wikipedia.org/wiki/SQL#Procedural_extensions http://en.wikipedia.org/wiki/SQL#Procedural_extensions It looks like a lot of vendors still only support propriatary extensions.

moheeb 15y ago

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.

eeperson 15y ago
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.

badmonkey0001 15y ago

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.

eeperson 15y ago
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.