Declarative and functional in nature. Just a manifest wiring functions into a DAG and a Postgres SQL functions that manage the graph of state machines. Simple in principle and very opinionated.

Replaces 240 lines of manual pg_cron -> pgmq -> Supabase Edge Function boilerplate with 20 lines of explicit DAG definitions. Currently Supabase-only (leverages their primitives) but planning to make it agnostic for vanilla Postgres setups.

Live demo / explanation here: https://demo.pgflow.dev

i remember their anti cheat was utter crap tbh, not like something that Riot implemented for Valorant (a kernel-level system that runs from boot-up with deep system access)

i'm curious if you made any bechmarks but focused on LLMs being able to read that format with your teaching prompt?

I'm really curious what would be the appropriate solution for an anti cheat that runs on Linux in a way that a) does not compromise my OS/privacy/security b) protects the game from cheaters at the same time.

I have a close friend who buried his depression under a pile of games built around these temporal reward loops. He’s not working and still living with his parents at 40.

Thank you for sharing this - awareness of these patterns needs to be spread.

Given i work in Tmux, its super convenient to take a laptop with me and just use it as a thin client to my Desktop wherever I am.

[0] https://netbird.io/

I never worked with WalEx but have experience with Supabase Realtime and it is a joy to work with and fits great into the Supa ecosystem. So many layers are disappearing when you rely more on Postgres!

[0] https://github.com/supabase/realtime [1] https://github.com/cpursley/walex

That said, there ARE other places that would benefit from triggers (aggregate counts). I've avoided them because they're hot paths and I was worried about perf impact - relyi ng on pgTAP coverage instead.

Your defense-in-depth argument is solid though. I should revisit this and benchmark whether the safety is worth the perf cost. Something like RegreSQL would come in handy

I was postponing proper, dedicated performance testing for some time and would really love to up my game in that regard.

I'm very happy with pgTAP approach of running stuff in transaction and rolling them back after the test - how this works in RegreSQL?

Would love to provide feedback and test the hooks when you will be working on them. I'm mostly interested in performance testing and my use case would be to run them on CI and compare to previous metrics stored somewhere in order to fail CI when performance regressions are introduced.

Happy to connect, got contact info in my profile.

I'm wondering how I would be able to regression-test functions in my project (pgflow [0]) - it tracks a graph of state machines modeled in few tables. State is mutated only by calling few exposed SQL functions (task queue worker does it).

Given I can't enforce everything I need with check constraints and I try to avoid triggers if possible, I opted for only using exposed SQL API [1] for setting up state in my pgTAP tests.

It is imperative and harder to maintain, like scripts you described in the article, but really my only option, as I want to have maximum confidence level.

Does RegreSQL support some kind of init scripts or I would need to wire it myself and just run RegreSQL after the proper state is set? Would lose the "run once and get report on everything" benefit then :-(

[0] https://pgflow.dev/ [1] https://github.com/pgflow-dev/pgflow/blob/main/pkgs/core/sup...

I love the idea of relying on markdowns and filesystem as universal API .The progressive discovery is great and very flexible and I'm regularly extracting parts of my workflow to small, focused skills.