> Perhaps something like this would be more readable > > WITH t AS ( > UPDATE ( SELECT 1 AS ctr, 'x' as val ) > SET ctr = ctr + 1, val = val || 'x' > WHILE ctr <= 100 > RETURNING ctr, val > ) > > The notion of an UPDATE on an ephemeral subquery isn't that special, see > "subquery2" in > https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/update_statement.htm ,
I must admit that I do not like much needing another level of subquery, but maybe it could just be another named query in the WITH statement.
So like this: WITH initial_conditions as (SELECT 1 as ctr, 'x' as val) UPDATE initial_conditions SET ctr = ctr + 1, val = val || 'x' WHILE ctr <= 100 RETURNING ctr, val
ISTM that UPDATE is quite restrictive as the number of rows cannot change, which does not seem desirable at all? How could I add or remove rows from one iteration to the next?
My understanding was that maintaining a fixed number of rows was a desired feature.
ISTM that the WHILE would be checked before updating, so that WHILE FALSE does nothing, in which case its position after SET is odd.
True, but having the SELECT before the FROM is equally odd.
Having both WHERE and WHILE might look awkward.
Maybe an UNTIL instead of WHILE?
Also it looks much more procedural this way, which is the point, but also depart from the declarative SELECT approach of WITH RECURSIVE.
Yeah, just throwing it out as a possibility. Looking again at what I suggested, it looks a bit like the Oracle "CONNECT BY level <= x" idiom.
I suspect that the SQL standards body already has some preliminary work done, and we should ultimately follow that.
