Re:Sudoku solver in SQL
by jcw on Wednesday September 02, 2009 @01:11PM
(#800611)
This is really cool.
I thought one of the design decisions of SQL was that it would NOT be Turing complete, so hacks like this could not exist. It's funny that the nature of a database makes things like this possible. Can a turing machine be made only using SQL queries? Could a higher-level language compile to it?
Re:Sudoku solver in SQL
by makmanalp on Wednesday September 02, 2009 @01:33PM
(#800679)
In my humble opinion, there are so many proprietary and / or nonstandard extensions to SQL that it's turned into a right mess. I think that the language itself is a bit kludgey and it'd be much easier if it'd just correspond to relational algebra directly. (Eg if you do a select * from foo where x = y, you're actually doing two operations, a select and a filter, and the natural language like syntax of the language makes it very ambiguous and confusing when you're dealing with complicated structures like nested joins and such)
Re:Sudoku solver in SQL
by kevindication on Wednesday September 02, 2009 @01:33PM
(#800682)
Of course this is just a silly hack so I can't be too hard on style here, but it would have been worth it to make a table for the input/output. An argument list of 81 values is painful to see.
http://algebraicthunk.net/~dburrows/blog/entry/package-manag...
I thought one of the design decisions of SQL was that it would NOT be Turing complete, so hacks like this could not exist. It's funny that the nature of a database makes things like this possible. Can a turing machine be made only using SQL queries? Could a higher-level language compile to it?
http://github.com/vishsingh/lisp-toronto/blob/80ea008e80976d...
http://www.celko.com/puzzles.htm (first part) vs http://sqlblog.com/blogs/hugo_kornelis/archive/2007/10/04/ho... (Celko replies in the comments)