Robert Haas <robertmh...@gmail.com> writes: > I think that would largely be rehashing previous discussions, in which > it's already been established that we don't see eye to eye on this > issue. But briefly, I think that replacing shared libraries ought to
Partly yes, but as I'm feeling that we are getting closer than ever to a consensus of a first move to be made, I want to be sure to understand the limits of that very move so that I'm able to implement the list consensus and nothing else. While I don't agree with all you said in your answer, I clearly understand that part: per-database management of modules is its own can of worms and another discussion and patch altogether. > Maybe these problems are solvable, but as things stand > today I think that trying to use identically-named .so files in > different databases at the same time should be regarded as dangerously > unsupported. In any event, any kind of infrastructure intended to > support such use cases is clearly a different project from simply > allowing modules to be loaded from a different location. Baring objections, I'll then implement a patch for allowing the core code to load modules from a per-cluster location within $PGDATA. The patch should also have a new initdb option much alike -X for pg_xlog so that it's possible to relocate that new per-cluster modules directory anywhere on the file system at initdb time. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
