Josh Berkus <[EMAIL PROTECTED]> writes:
> The way the SQL scripts currently work, there is no way to manage what
> schema the contrib modules get built in *except* to edit the scripts.
Right, that's the intended and documented way to do it.
> In fact, because of the SET statements, a DBA who might *reasonably*
> expect that setting PGOPTIONS would allow him to determine that will be
> unpleasantly surprised when the module ends up in "public" anyway.
I don't see that this is a reasonable expectation; it has never worked
in any previous release, and the documentation explicitly says to do the
other. Also, at least some of the proposed forms of a module facility
would have the effect of overriding any such approach anyhow.
Again, I'm not for whacking around the procedures for dealing with
contrib each time we make a release. We should change it once when we
have a shot at getting it right.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
