Re: Extension Templates S03E11

On 12/16/13, 1:00 PM, Josh Berkus wrote:
> On 12/16/2013 10:53 AM, Josh Berkus wrote:
>> Some PostgreSQL shops with lots of servers have large internal libraries
>> of functions, views, and similar code that they've written to support
>> their applications, which don't comprise a complete database. This
>> feature would allow them to "package" those libraries, and version,
>> upgrade and track them, without requiring a filesystem-based install. I
>> myself have a couple clients who could benefit from this.
>
> cc'ing Jim Nasby, since I think Enova is part of the target market for
> this feature. Jim, have you taken a look at this?

The name rings a bell; I think I looked at it in the past.

I've read all of this thread that I've currently got (back to 12/11), so I think I've got some idea what's going on.

Enova definitely has libraries of objects, and in fact we're currently working on releasing them via PGXN. That's proving a bit challenging since now we have to find a way to incorporate PGXN into our existing deployment framework (I do NOT want users to have to manually run pgxn client commands). Another complication is that we don't want our production servers downloading random, un-audited code, so we need an internal PGXN mirror.

I think it's probably best if I describe the issues that we've run across, to help the rest of the community understand the pain points. I'll work on doing that.

In the meantime, I can say this:

- Being forced to put files down for extensions is a PITA
- We don't have a good way to deal with extensions that have been installed in a non-standard schema, other than search_path, which for a complex database is impractical
- There's a lot that could potentially be done without any external libraries (we've got the equivalent of probably 6-8 modules, none of which require C and only one uses a Perl module (which is part of the module itself; the only reason for the .pm is to properly factor the code between plperl functions)
- We definitely need a mechanism for declaring deps between modules

Somewhat related to this, I really wish Postgres had the idea of a "class", that was allowed to contain any type of object and could be "instantiated" when needed. For example, if we had an "address class", we could instantiate it once for tracking our customer addresses, and a second time for tracking the addresses customers supply for their employers. Such a mechanism would probably be ideal for what we need, but of course you'd still have the question of how to load a class definition that someone else has published.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net