Re: ALTER EXTENSION UPGRADE, v3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-10 20:52:29
Message-ID: 4148.1297371149@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Now, if you want to argue that moving an extension after the fact (ALTER
>> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
>> argue very hard. Do you want to propose ripping that out? But
>> relocating at first install doesn't seem horrible.

> I'm not very concerned about letting people set the schema after the
> fact. If we think it's OK for them to whack the location around at
> first install, I don't know why we shouldn't also let them whack it
> around later.

The argument was that whether it's safe to move it during initial
install is strictly a property of the extension's own internals. Once
it's been in the database for awhile, moving it safely depends not only
on the extension's internals but also on whether you have created any
*other* objects that depend on where the extension is; for example,
functions that have its schema name embedded in a SET search_path
property or even hardwired in their code.

However, this risk isn't really any different from when you do ALTER foo
SET SCHEMA on a "loose" object, so on reflection it's not clear to me
that we should refuse this case when we allow the latter. We're merely
allowing people to shoot themselves in the foot with a machine-gun
instead of a revolver, by providing a command that encapsulates a whole
lot of SET SCHEMA commands in one action.

> The real issue is what happens when you want to install
> extension A, which depends on extensions B, C, and D, and B, C, and D
> are all in non-standard locations. Does that have any chance of
> working under the system we're proposing?

Again, it's not really any different from the case where the dependent
objects are "loose" rather than members of an extension. It's pretty
much up to the user to be aware of the consequences. If we had a way to
mark individual functions as safe or unsafe for renames to happen, it'd
be reasonable to extend that notion to whole extensions. But we don't
have that and I don't think it's appropriate to hold extensions to a
higher standard than we do loose objects --- especially when it takes
superuser privileges to break things by moving an extension but not to
break them by moving loose objects.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tobias Brox 2011-02-10 20:55:29 Re: Why we don't want hints Was: Slow count(*) again...
Previous Message David E. Wheeler 2011-02-10 20:46:24 Re: ALTER EXTENSION UPGRADE, v3