From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extensions, this time with a patch |
Date: | 2010-10-20 14:46:09 |
Message-ID: | 1287585839-sup-1518@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Dimitri Fontaine's message of mié oct 20 07:22:53 -0300 2010:
> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-10-20 14:46:53 | Re: Extensions, this time with a patch |
Previous Message | Stephen R. van den Berg | 2010-10-20 14:44:53 | Re: pg_rawdump |