It just relates to trusted languages such as PL/pgSQL. What we're talking about here does not relate at all to shared library extensions or C extensions though. Many extensions actually contain not just a SQL schema definition, but also a shared library object where the extension is written in C. You're essentially running a SQL file in the server to create this extension and all the objects created by the extension are also associated to it. So, if you run a DROP EXTENSION later, it will remove all the schema objects that the extension file contained. This takes an extension name which is loaded from a file.
The other thing to understand is that Postgres has the CREATE EXTENSION mechanism. So, PL/pgSQL is considered trusted versus PL/PythonU is not, because PL/PythonU actually allows you to access the server file system and ultimately become root or super-user or something else on the system. For example, PL/pgSQL gets created automatically, but behind the scenes it calls CREATE TRUSTED LANGUAGE plpgsql. In Postgres, when you have the notion of "Trusted", what this refers to is languages that do not allow access to the database server internals or the file system. Have a look at the article if you’d like, but I'll jump right into what this is about and why they created this. This is an announcement about Trusted Language Extensions for PostgreSQL on Amazon Aurora and Amazon RDS that came out during the AWS re:invent event this week. Let's have a look! Trusted language extensions for Postgres What we have discussed in this episode of 5mins of Postgres
#Aurora postgresql logo password#
Using pg_tle with Postgres hooks: The password check hook.Using the pg_tle Trusted Language Extension.
Pg_tle: Postgres Trusted Language Extensions
0 kommentar(er)
