You may have noticed, that some of the PLs in PostgreSQL can be declared as untrusted. They all end in the letter u to remind you that they are untrusted each time you use them to create a function. Unrestricted languages allow you to do things that restricted or trusted languages are not allowed to do; for example, interacting with the environment and creating files and opening sockets. In this chapter, we will look at some examples in detail.
This untrustedness brings up many questions:
- Does being untrusted mean that such languages are somehow inferior to trusted ones?
- Can I still write an important function in an untrusted language?
- Will they silently eat my data and corrupt the database?
The answers are no, yes, and maybe respectively. Let's now discuss these questions in order.
No, on the contrary, these languages are untrusted in the same way that a sharp knife is untrusted and should be kept out of the reach of very small children, unless there is adult supervision. They have extra powers that ordinary SQL, or even the trusted languages (such as PL/pgSQL) and trusted variants of the same language (PL/Perl versus PL/PerlU) don't have.
You can use the untrusted languages to directly read and write on the server's disks, and you can use it to open sockets and make Internet queries to the outside world. You can even send arbitrary signals to any process running on the database host. Generally, you can do anything the native language of the PL can do.
However, you probably should not trust arbitrary database users to have the right to define functions in these languages. Always think twice before giving all privileges on an untrusted language to a user or group, by using the *u languages for important functions.