> Now we think that we were wrong. This type of query should run into > infinit recursion and it's user's responsibility that he does not make > such a query. > > Another idea would be prohibiting *any* outer joins in the recursive > term (DB2 style), but this may be overkill.
Even if you were to do that, I'm pretty sure that you'd find that it is insufficient to prevent infinite recursion. I suspect it's not difficult to show that SQL with WITH RECURSIVE is Turing-complete, and therefore detecting infinite recursion is equivalent to the Halting problem. http://en.wikipedia.org/wiki/Halting_problem Even if it isn't, someone can always call a function written in any of the procedural languages, which is definitely sufficient to make it Turing-complete. Then you don't even need WITH RECURSIVE: rhaas=# create or replace function keep_going() returns setof integer as $$ begin loop return next 1; end loop; end $$ language plpgsql; CREATE FUNCTION rhaas=# select * from keep_going(); <...> The way to attack this is by putting in some kind of logic that cuts the query off when the result-set gets too large or consumes too much memory or CPU time or something along those lines. Actually detecting or preventing infinite loops is impossible, and not the real goal anyway, since a query that generates 10^100 rows is for all practical purposes just as bad. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
