ON THE POSITIVE SIDE: I corrected some errors from my "
proof of concept", and now my implementation gives the right results. For example, here's the query with 3 character permutation results (you can see the positive and negative signs used in the SJT algorithm):

WITH starter AS (
SELECT '123456' AS word FROM DUAL
),
...
AND halt = 'no'
), display as (
SELECT loop#+1 as permutation#
, listagg(abs(val#),',') WITHIN GROUP (order by pos#) as permutation
FROM mobilizer
WHERE step# = 0
GROUP BY loop#
)
SELECT count(*)
FROM display
ORDER BY 1;
COUNT(*)
---------------
720
Elapsed: 00:00:50.52

DISCUSSION: For each of the 720 results, my SJT implementation executes three steps, so there are 2,160 records (plus the base record) created.

The naïve implementation generates all 1,956 permutations/records from length 1 through length 6.

First, I'm using separate rows for each letter of the permutation (a "vertical" SJT implementation) -- a step I took with some foreboding-- rather than one row per permutation ("horizontal" naïve implementation) ... that could have significant implications; it may not be a "
level playing field".

My SJT implementation uses analytics for 2 of 3 steps for each permutation. That should be fast, but apparently not as fast as the simple string search and joins used in the naïve implementation.

For a longer string, like 'RESPECT' the differences are striking. The "simplementation" generates 13,669 permutations in order to create the final set of 5,040 records of length 7.

If I let my SJT implementation complete (I haven't, it's slow), it should generate 3*5040 or just over 15,000 records. So it's generating slightly more records using more complex computations.

There's a more complex version of SJT called "
Even's Speedup". However, I think it's time to halt this line of permutation generation exploration, at least for now.

CONCLUSION: I've demonstrated it's possible to implement a modest algorithm using recursive SQL. But what's
possible may not be
desirable.

Or maybe there's a better SJT implementation in SQL? I leave it to greater minds than my own. Perhaps recursion and regular expressions so it's a "horizontal" implementation where you initialize the algorithm with a string like this?