Re: Dumping an Extension's Script

Heikki Linnakangas <hlinnakangas(at)vmware(dot)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