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
>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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to