| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ALTER OBJECT any_name SET SCHEMA name |
| Date: | 2010-11-05 20:15:30 |
| Message-ID: | m2lj57edct.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Basically you're saying that the owner of the schema in which the
> extension is installed can drop the extension ... even though, according
> to your previous argument, the extension is not "in" said schema :-)
Yeah it's a case of defining things. The extension is not in the schema,
it depends on it. So if you drop schema cascade, that cascades to drop
extension.
I'm not saying that the only way to do it sanely is the one I propose,
but I did consider some alternatives and I did not code the current
patch only by accident :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-11-05 20:16:40 | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |
| Previous Message | Alvaro Herrera | 2010-11-05 20:04:48 | Re: ALTER OBJECT any_name SET SCHEMA name |