Re: Final /contrib cleanup -- yes/no?
| От | Tom Lane |
|---|---|
| Тема | Re: Final /contrib cleanup -- yes/no? |
| Дата | |
| Msg-id | 16137.1226010249@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Final /contrib cleanup -- yes/no? (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: Final /contrib cleanup -- yes/no?
|
| Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> 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
В списке pgsql-hackers по дате отправления: