diff --git a/posts/2022-12-25.md b/posts/2022-12-25.md
index f008873..9594d19 100644
--- a/posts/2022-12-25.md
+++ b/posts/2022-12-25.md
@@ -26,13 +26,13 @@ WITH
         FROM symm e1, symm e2
         WHERE e1.b = e2.a
     )
--- Produce triples (a, b, c) where symm(a, c) and symm(a, b, c) exist.
+-- Produce triples (a, b, c) where symm(a, c) and path2(a, b, c) exist.
 SELECT DISTINCT path2.a, path2.b, path2.c
 FROM path2, symm
 WHERE path2.a = symm.a
   AND path2.c = symm.b;
 ```
-You can even use the bindings in subsequent expressions, as we did with `edges` in `path2`.
+You can even use the bindings in subsequent expressions, as we did with `symm` in `path2`.
 
 Excitingly, the SQL folks realized that something really neat happens if you allow a binding to refer to itself.
 Hearts full of excitement (one imagines) they introduced the `RECURSIVE` modifier that allows this.
@@ -157,7 +157,7 @@ Let's discuss a few differences from SQL's `WITH RECURSIVE`:
 1.  We had to specify the type of the column of `numbers`. 
     We require this to make the SQL type resolution substantially easier, and not involve a recursive fixed-point problem when coercable types are used.
     I can imagine we could relax this in the future, bit it isn't meant to be the most important difference.
-2.  We had to add the constraint `t2.n <= 256`.
+2.  We had to add the constraint `t2.n < 256`.
     The absence of this constraint from the SQL version, and its termination nonetheless, still blows my mind.
     Of course you have to bound this, otherwise we would continue increasing `numbers` through the contributions of `t2` even with a bounded `t1`.
 3.  We had to type `MUTUALLY`.