AW: AW: AW: "setuid" functions, a solution to the RI pr ivil ege problem

Since you can write extensions to PostgreSQL that reach far into the OS,
it does make sense to execute those extensions under a "non priviledged"
user, and not postgres.

Agreed.

This OS user would somehow be tied to the username that the client
passes as his credentials (and that we trust to be authenticated).

Not agreed. It's a feature, not an accident, that client user names,
server OS user names, and database user names are independent. The mapping
of database user names to server OS user names needs to have a separate
mapping

Yes, a mapping is useful (as I said).

and authentication system, which could probably be similar to the
existing client authentication, but still separate.

I do not think that a separate authentication is necessary, it might be a
feature,
but imho the standard would be a trusted mapping from db to OS user.
Remember that execution rights are granted to db users for functions.
If a user does not have a desirable mapping you don't grant him any rights.

A special flag "suid" for functions would imply that the function always
runs under
the same OS user of the function owner, regardless of client credentials.

Andreas