Re: Configurable location for extension .control files

On 3/4/15 1:41 AM, Oskari Saarenmaa wrote:
>> >I'm interested in this because it could potentially make it possible to
>> >install SQL extensions without OS access. (My understanding is there's
>> >some issue with writing the extension files even if LIBDIR is writable
>> >by the OS account).
> I'm not sure this patch makes extensions without OS access any easier to
> implement; you still need to write the files somewhere, and someone
> needs to set up the cluster with a nonstandard extension path.

Right, I wasn't expecting it to work out of the box.

Admittedly I'm foggy on what the exact problem with pushing a file into 
that directory via SQL is, so maybe it still won't help.

>>> >>I don't think anyone should be packaging and shipping PG with
>>> >>extension_directory set, but we really should allow it for superusers
>>> >>and postgresql.conf so people can test extensions without hacks like
>>> >>this:https://github.com/ohmu/pgmemcache/blob/master/localtests.sh#L23
>> >
>> >FWIW I'd like to see is breaking the cluster setup/teardown capability
>> >in pg_regress into it's own tool. It wouldn't solve the extension test
>> >problem, but it would eliminate the need for most of what that script is
>> >doing, and it would do it more robustly. It would make it very easy to
>> >unit test things with frameworks other than pg_regress.
> This would certainly be useful.  I can try to do something about it if
> we get configurable extension path supported.  The patch is now in
> https://commitfest.postgresql.org/5/170/

Awesome! Let me know if I can help. Or I may start on it if I can get 
some other stuff off my plate.

By the way, after thinking about this a little more, I think a utility 
for standing up "temporary" Postgres clusters would be very welcome by 
power users. It's a very common need for QA environments. Originally I 
was thinking about it in terms of things like extension testing, but now 
I realize there's a much larger audience than that. So I definitely 
think this should be a stand alone shell command (pg_temp_cluster?), and 
either have pg_regress call it or (probably more logical) add it to the 
make files as a dependency for make check (make 
temp-cluster/remove-temp-cluster or similar).
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com