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.

Everyone loves a good Easter egg

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 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.