Could be added to SQL test suites tbh
This brings back memories of trying to do weird things in SQL for fun. It is such a cool concept.
It is... surprisingly readable, if you have any experience with QR code generation.
Author here. I had a vague idea of what would be needed for building such QR codes, but not all stages. As I mentioned in my blog, I worked with codex, so I did this:
1) ask codex to list what are the stages/components needed for QR code generation in general
2) told codex to build a QR code generator based on these stages in SQL. - It went off the rails and started addding "plsql" stuff for some matrix operations, etc. - I added guidance saying that you can just use string_agg(), array_agg() and either nested loop driven or recursive iteration through the space
3) Then it generated QR-code looking codes, but they were not readable
4) I then installed the "qr" utility to my machine and instructed codex to iterate through its fixes and compare the SQL output to "qr" output, that got it working for some QRs
5) I then created a test suite that was just a 5 line shell script that ran 1000 QR code generations with random text inputs both with SQL and "qr" and diffed the outputs (and bailed out immediately once it found the first mismatch)
I then instructed codex to always run the full "test suite" when iterating changes and that got me to the final result - all work took just an hour.
I think if this could be run in a production environment, it would also be fun. Even though it has been stated that it is only for personal enjoyment.
Everyone loves a good Easter egg
Reading the code felt a little eye opening about what programming can be. Slightly like learning a bit of Haskell. Even though sql is so familiar.
The pure SQL approach is impressive. Would be interesting to see performance comparisons with traditional QR libraries at scale.
I would hope it's at least 3-4 orders of magnitude slower than a "traditional QR library". It'd be quite the indictment for such libraries, if not.
> I did this purely for fun and learning, I don’t think this is going to be the best way for generating QR codes in production.
And yet, someone somewhere is under pressure to "just get it done" and generate QR codes from URLs in a database.
I never got to comparing the exec plans between PostgreSQL 16 and 17. The latter ran much faster, if you (or anyone) have time, please test on 16 and 17 (and 18) with explain (timing=on) and put it through some online plan explainer (and write a post about it).
Happy to link to it in my blog.