Contrib, schema, and load_module
Folks,
Magnus and I decided to take on the annual /contrib cleanup for the code
sprint here at pgWest. One of the areas we realized needs cleanup is
the use of schema with the modules -- Magnus, Bruce and I all think that
contrib modules really need to create and use their own private schema.
Reasons:
-- user access to specific modules
-- backup/restore
-- upgrading modules
-- namespace conflicts (currently, we don't test for these)
However, this brings up some questions:
1) should the private schema names be "module_name" or "pg_module_name"?
If the latter, what about pgbench and pgcrypto?
2) how do we give DBAs an easy search path for the simplest case, where
they want all users to have access to all loaded modules?
3) what work was actually done on load_module() by Tom Dunstan, which
might make this unnecessary?
--Josh Berkus
Josh Berkus wrote:
3) what work was actually done on load_module() by Tom Dunstan, which
might make this unnecessary?
This link appears on Todo:
Improve the module installation experience (/contrib, etc)
* modules
* Re: PostgreSQL extensions packaging
* Database owner installable modules patch
It seems that the real way forward is to improve on that patch.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
Josh Berkus wrote:
3) what work was actually done on load_module() by Tom Dunstan, which
might make this unnecessary?This link appears on Todo:
Improve the module installation experience (/contrib, etc)
* modules
* Re: PostgreSQL extensions packaging
* Database owner installable modules patchIt seems that the real way forward is to improve on that patch.
But Tom hasn't done anything since April? That's what I'm asking.
--Josh
Alvaro Herrera <alvherre@commandprompt.com> writes:
It seems that the real way forward is to improve on that patch.
Yeah. If the schema-per-module answer were really a good answer,
we'd have done it before now. But you need more infrastructure
than just a schema to get good things to happen. Aside from the
search-path-hell issue, a schema alone doesn't solve the problem
of persuading pg_dump to dump a "load module" command rather than
the individual module components.
regards, tom lane
Josh Berkus wrote:
But Tom hasn't done anything since April? That's what I'm asking.
What's the surprise? I gathered that Tom is itinerant. If he's not
here and we want to job to be done, somebody else must do it.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Le 11 oct. 08 à 01:50, Tom Lane a écrit :
Alvaro Herrera <alvherre@commandprompt.com> writes:
It seems that the real way forward is to improve on that patch.
Yeah. If the schema-per-module answer were really a good answer,
we'd have done it before now.
I tried to spend some time thinking about those issues and came up
with a packaging management proposal, which I still think has merits.
One of them is to propose to reuse existing stuff and Tom Dunstan's
preliminary work.
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01098.php
Hope this helps,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkjwmCQACgkQlBXRlnbh1bmIggCdGqD8TwJE7CeZDCL+v5njPtib
4+kAoLVj3rDzsFpJvb/Zc20R+Jo/s5Z7
=O6C6
-----END PGP SIGNATURE-----
2008/10/11 Dimitri Fontaine <dfontaine@hi-media.com>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi,
Le 11 oct. 08 à 01:50, Tom Lane a écrit :
Alvaro Herrera <alvherre@commandprompt.com> writes:
It seems that the real way forward is to improve on that patch.
Yeah. If the schema-per-module answer were really a good answer,
we'd have done it before now.I tried to spend some time thinking about those issues and came up with a
packaging management proposal, which I still think has merits. One of them
is to propose to reuse existing stuff and Tom Dunstan's preliminary work.
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01098.php
did you look to SQL/PSM standard?
Regards
Pavel Stehule
Show quoted text
Hope this helps,
- --
dim-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)iEYEARECAAYFAkjwmCQACgkQlBXRlnbh1bmIggCdGqD8TwJE7CeZDCL+v5njPtib
4+kAoLVj3rDzsFpJvb/Zc20R+Jo/s5Z7
=O6C6
-----END PGP SIGNATURE-------
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom,
Yeah. If the schema-per-module answer were really a good answer,
we'd have done it before now. But you need more infrastructure
than just a schema to get good things to happen. Aside from the
search-path-hell issue, a schema alone doesn't solve the problem
of persuading pg_dump to dump a "load module" command rather than
the individual module components.
I have faith in nothing historical regarding /contrib, which has been
largely characterized by maintenance neglect.
However, it sounds like waiting for something like Dimitri's package
manager is the way to go rather than messing with schemas without other
instruments in place. I'll just go through and replace the BEGIN ...
COMMITS in the SQL scripts, which Bruce admits he deleted without really
thinking about it.
--Josh
Dimitri,
Am I correct in assuming, however, that you're not at all likely to
complete this for 8.4?
--Josh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Le 11 oct. 08 à 21:10, Josh Berkus a écrit :
Am I correct in assuming, however, that you're not at all likely to
complete this for 8.4?
Not only that, but as I've yet to discover PostgreSQL internal code,
it would ask a lot of help and efforts to get something in shape even
in the 8.5 timeframe. If recent events are showing anything, we can
trust the #postgresql crowd to provide the help, and I could
organise myself around the time & efforts.
Just don't suppose this could happen realistically for 8.4... that is,
by the end of this month.
Regards,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkjw/zEACgkQlBXRlnbh1bn+NACgjPIz+p9X36E8xlhcML7t+0Tx
EpkAnA8eYhIPCHwttDg4rs7Eab3XnrfC
=+Qsq
-----END PGP SIGNATURE-----