Re: ALTER EXTENSION UPGRADE, v3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER EXTENSION UPGRADE, v3
Дата
Msg-id 4148.1297371149@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION UPGRADE, v3  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: ALTER EXTENSION UPGRADE, v3  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: ALTER EXTENSION UPGRADE, v3  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: ALTER EXTENSION UPGRADE, v3
Следующее
От: Robert Haas
Дата:
Сообщение: Re: ALTER EXTENSION UPGRADE, v3