steve-chavez

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]:

[1]: https://github.com/orangeduck/mpc/commits?author=steve-chave...

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

[1]: https://github.com/PostgREST/postgrest/blob/f1d0e8ea2266077d...

[2]: PostGIS has https://postgis.net/docs/AsTopoJSON.html but it doesn't take a record.

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.

[1]: https://github.com/PostgREST/postgrest/blob/main/CONTRIBUTIN...

> It's a replacement for SQL, the language

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.

[1]: https://supabase.com/docs/guides/platform/read-replicas#api-...

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

I played starcraft2 13 years ago on Linux, the wizard installer worked just fine.

Not really, the work is much reduced.

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.

[1]: https://docs.postgrest.org/en/v12/references/api/functions.h...

[2]: https://supabase.com/docs/guides/local-development/declarati...

Yes, it does many-to-many joins automatically: https://docs.postgrest.org/en/v12/references/api/resource_em....

> My server is going to provide an API that isolates the application from the DB structure.

The same can be achieved with "schema isolation". See https://docs.postgrest.org/en/v12/explanations/schema_isolat....

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

For more details, see https://docs.postgrest.org/en/v12/explanations/schema_isolat....

I think you want to link to https://news.ycombinator.com/item?id=41956044.

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.

[1]: https://github.com/kuruczgy/x1e-nixos-config

The TLDR is that Nginx offers about x2 more throughput than Caddy.

That's false. On the same youtube channel there's a video [1] comparing Nginx vs Envoy and Nginx offers higher throughput.

Besides that, from what I've seen Envoy has a higher dependency footprint:

- It comes bloated with GRPC functionality.

- Configuration requires running python.

I'd be glad to be proven wrong on the performance side of Envoy but so far I've only heard rumors and never seen a conclusive benchmark.

[1]: https://www.youtube.com/watch?v=0Q9I-x--np4

The TLDR is that Nginx offers about x2 more throughput than Caddy.

Transactions are done using database functions https://docs.postgrest.org/en/v12/references/api/functions.h....

You have explicit control over transactions with functions https://postgrest.org/en/latest/references/api/functions.htm....

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.

[1]: https://github.com/supabase/postgrest-js

[2]: https://github.com/PostgREST/postgrest/issues/286

Yes, sorry about that. We're looking at it on https://github.com/PostgREST/postgrest/issues/3503.

> * there is no column level security – e.g. I want to show payment_total to admin, but not to user

I think what you want is dynamic data masking. RDMBSes like IBM DB2[1] and SQL Server[2] offer it out of the box.

For PostgreSQL, there's the postgresql_anonymizer[3] extension. For which you could do something like:

  SECURITY LABEL FOR user ON COLUMN invoice.payment_total
  IS 'MASKED WITH VALUE $$CONFIDENTIAL$$';

Last time I tried it though, it didn't play well with transaction variables (`current_setting(my.username)`), so you could not combine it with RLS logic and application users[4]. I'll be exploring an alternative on https://github.com/steve-chavez/pg_masking.

To be fair, this discussion is more related to a PostgreSQL feature than PostgREST. PostgREST relies on PostgreSQL for all authorization logic by design.

[1]: https://www.ibm.com/docs/en/db2-for-zos/12?topic=statements-...

[2]: https://learn.microsoft.com/en-us/sql/relational-databases/s...

[3]: https://postgresql-anonymizer.readthedocs.io/en/latest/decla...

[4]: https://www.2ndquadrant.com/en/blog/application-users-vs-row...

> This is especially grating since the rest of the tooling seems to try to take me away from SQL a lot by using Postgrest.

You're actually encouraged to write SQL with PostgREST, see this other comment https://news.ycombinator.com/item?id=40046710

> PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.

The PostgREST query grammar is basic on purpose, you're supposed to write SQL on views or functions[1] to extend its capabilities.

[1]: https://postgrest.org/en/v12/references/api/stored_procedure...

> A few things, RLS is secure by default, it's postgrest that's insecure by default.

What makes you think that? PostgREST delegates all the authorization to PostgreSQL, which is secure by default. You have to explicitly assign privileges to roles for every operation.

Relevant previous discussion: https://news.ycombinator.com/item?id=38689294

Simon Riggs's 2ndQuadrant was one of the first patreons for PostgREST. I'll forever be grateful, their support came in a hard time. Rest in peace Simon.

Yes, it's Nix! Supabase already uses Nix on some projects like https://github.com/supabase/nix-postgres/

Answered that above: https://news.ycombinator.com/item?id=38692597

We've also updated the doc with some manual sanitization[1], but that's definitely not the final form of this POC.

[1]: https://postgrest.org/en/stable/how-tos/providing-html-conte...

> Already PostGREST is getting complicated, additions like this will make it less attractive to me.

This feature[1] actually simplified a lot and removed a lot of magic assumptions in the PostgREST codebase. It goes in line with REST as well — SQL functions are REST resources and HTML is just another representation for them.

Most of the code you see here is pure SQL and plpgSQL. The only PostgREST-specific part is the CREATE DOMAIN.

Right now most users view PostgREST as a HTTP->JSON->SQL->JSON->HTTP service and we're trying to turn that into HTTP->SQL->HTTP. If that's not some true top level simplification, I don't know what is!

[1]: https://postgrest.org/en/stable/references/api/media_type_ha...

We segregate responsibilities so no one has complete control of the PostgREST project. For example, begriffs[1] is in charge of handling the funds (Patreon), wolfgangwalther[2] owns the .org and .com domains and both are owners of the PostgREST's GitHub org. For development, this ensures I don't go crazy and add some feature that is Supabase-specific, since I'm not the only one who has a say in the project's direction.

This has been working well until now and if you follow PostgREST's development, you'll notice that all enhancements are vendor-neutral and keep the original design.

We're a much smaller team but we took some inspiration from PostgreSQL distributed model (no single company owns development) for this.

[1]: PostgREST author https://github.com/begriffs

[2]: Also part of the PostgREST team and major contributor https://github.com/PostgREST/postgrest/graphs/contributors

This doc was meant to be a POC, just to show what's possible. We're working on migrating it to Mustache templates which do automatic escaping: https://github.com/PostgREST/plmustache?tab=readme-ov-file#e...

You're right though, we'll add a warning there. Thanks for the feedback.