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 (email@example.com)
To make changes to your subscription: