Heikki Linnakangas <hlinnakan...@vmware.com> writes: > No doubt about that. I'm sure extensions written in pure SQL or PL/pgSQL are > very common. But what does that have to do with this patch?
This patch is all about enabling users to create extension without having to ship them as root on the file system of the database(s) server(s) first. When you're having to code your extension in C, you know you're in for shipping an executable binary (.so, .dylib or .dll), and for security reasons it's well understood that you will have to get root privileges on the server's file system to ship your binary before to be able to ask PostgreSQL to please load it and execute the code in there. When you can code your extension using dynamic code such as SQL or PL/pgSQL, PL/pythonu or PL/perl, there's absolutely no good reason to have to do the "ship on the server's file system first" that I can see. Technically creating an extension "inline" (sending its definition in the CREATE EXTENSION query itself) solves the problem of having to access the server's file system as root. Then, next pg_dump will include "CREATE EXTENSION foo;" as usual and at pg_restore time that access files on the file systems. But maybe you still are not granted access to the server's file system as root on the pg_restore target, right? So now you need to be able to include the extension's script into the dump. Now, we don't want to have more than one kind of extensions. That's what we learnt all together when reviewing my proposal from last year. Having more than one way to ship an extension is good, having two different animals with two different incompatible behaviors named the same thing is bad. The solution we found is then to be able to include an extension's script into pg_dump's output, and that's what my current patch implements, per last year review. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers