Re: Extensions, this time with a patch
От | Alvaro Herrera |
---|---|
Тема | Re: Extensions, this time with a patch |
Дата | |
Msg-id | 1287585839-sup-1518@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Extensions, this time with a patch (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Extensions, this time with a patch
|
Список | pgsql-hackers |
Excerpts from Dimitri Fontaine's message of mié oct 20 07:22:53 -0300 2010: > Itagaki Takahiro <itagaki.takahiro@gmail.com> writes: > > ==== CREATE EXTENSION command ==== > > * Environment could be modified by the installer script. > > =# SHOW search_path; => "$user",public > > =# CREATE EXTENSION dblink; > > =# SHOW search_path; => public > > because almost all of the modules have SET search_path in the scripts: > > -- Adjust this setting to control where the objects get created. > > SET search_path = public; > > > > Is is an intended behavior? Personally, I want the installer to run in sandbox. > > One idea is to rewrite module scripts to use BEGIN - SET LOCAL - COMMIT, > > but we cannot execute CREATE EXTENSION in transaction if do so. > > Using SPI to execute the extension's script already means that it can > not contain explicit BEGIN and COMMIT commands. Now, is it possible to > force a Reset of all GUCs after script's execution? Would it work to force a new transaction internally in CREATE EXTENSION, and use the equivalent of SET LOCAL in the CREATE EXTENSION code? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: