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 j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
