Many thanks! It took me a long time to come up with the interface. I've been wanting a good parser combinator library for C since 2023 when I contributed to mpc[1]:
Many thanks for your work pramsey. We use that exact function [1], do you have any plans for a similar function for TopoJSON? One that also has a record parameter? [2].
One thing that is missing is a standard no-LLM policy, like the "Contributor Covenant Code of Conduct". On PostgREST we recently added a strict no-LLM policy [1], basically linking Gentoo's AI policy, which we found the most apt in lack of a standard.
PostgREST doesn't provide a replacement, rather a subset of the SQL language meant to be safe to expose to untrusted (frontend) clients.
Load balancing is not built-in currently, but it can be done at the proxy layer, taking the advantage that GET/HEAD requests are always executed on read only transactions, so they can be routed to read replicas. This is what Supabase does [1] for example.
> PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over
Do note that by default in PostgreSQL/PostgREST, RLS is the third layer of AuthZ defense, you have table and column level security before and these are closed by default.
> In Supabase's model, it's a breach.
Supabase is currently working on being closed by default.
1. If your function returns a table type, you can reuse all the filters that PostgREST offers on regular tables or views [1].
2. The SQL code will be much more concise (and performant, which leads to less maintenance work) than the code of a backend programming language.
3. The need for migrations is a common complaint, but you can treat SQL as regular code and version control it. Supabase recently released some tooling [2] that helps with this.
> If my DB structure changes, I have to force new app versions on every platform because I didn't insulate back-end changes with an API.
To avoid the above problem, it's a standard practice in PostgREST to only expose a schema consisting of views and functions. That allows you to shield the applications from table changes and achieve "logical data independence".
So cool! For some reason navigating to Github/Discord by clicking the links is slow on my phone (old galaxy s20fe). The click highlight of the button is normal, just going to the sites is slow.
There's not much substance in the reply there, on one part there's this argument:
> Go programs are fast enough for Google, Netflix, Stripe, and many other large Internet companies… it’s probably fast enough for you
Which of course is an appeal to authority. Overall, it's pretty well known that a GC language will have downsides in perf when compared to system programming languages.
I also got one of these. AFAICT for Linux, we need to wait for kernel 6.12, which is still at the rc stage but should be ready at the end of this month. As a NixOS user, I'm keeping track of this repo [1] for support.
I think this sentiment stems from users of postgrest-js[1], which is a JS library that gives an ORM feel to PostgREST requests. Under that abstraction, users don't realize they're using a REST API, instead of a direct postgres connection.
So in this case users are really asking for "client-side transactions"[2], which are not supported in PostgREST.