By default, require superuser privileges to install a pgx extension

[vadim2404]

An error occurs when the user without root privileges tries to install extensions compiled via pgx.

For instance, pg_graphql is written on Rust using pgx. And if the user has access only to one database created especially for him, he'll see

create extension pg_graphql;

ERROR: permission denied for language c (SQLSTATE 42501)

It happens because the C language is untrusted by default in Postgres. These changes allow non-privileged users to install extensions without marking C as trusted.

[eeeebbbbrrrr]

I don't believe it's correct for the pgx extension template to default to trusted = true. That's not a decision pgx can make and so it ought to err on the side of safety.

And with that in mind, I'd say that setting superuser = false has actually been wrong all along.

In other words, it seems more correct for pgx to default to creating extensions that are untrusted and require superuser privileges to create. An extension developer can better make these decisions about their own extension.

[vadim2404]

@eeeebbbbrrrr, it makes sense. I've reverted the changes related to trusted

[eeeebbbbrrrr]

For future reference, please note that we prefer PRs made against the develop branch. I've updated it here.

I'm fine to merge this but I wouldn't mind @workingjubilee's input first (these options are documented at https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11).

Over the past year, Jubilee has taught me an entirely different perspective on safety and correctness.

[workingjubilee]

Yes, using superuser = true is correct according to this because even though superuser = false won't be an escalation of privileges, 99.9% of the time we will be creating a "C" language function which will fail to install. So we might as well do so immediately.

We are indeed working on making a subset of Rust installable without superuser privileges, but normally, pgx has all the capabilities needed to do "fun" things to a database. It requires the superuser's consent to do such things.

[eeeebbbbrrrr]

Funny how this PR got turned into the exact opposite of what was desired, but I'm glad we're all on the same page. Thanks @vadim2404, merging now.