Re: Extensions versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Extensions versus pg_upgrade
Дата
Msg-id 24500.1297217863@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Extensions versus pg_upgrade  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Having now looked at it a bit closer, I think the syntax choice is a
>> complete wash from an implementation standpoint: either way, we'll have
>> a list of bison productions that build AlterObjectExtensionStmt nodes,
>> and it goes through the same way after that.
>>
>> Preferences anyone?

> The closest exstant parallel is probably:

> ALTER SEQUENCE foo OWNED BY bar;

> I think paralleling that would probably be the most SQL-ish thing to
> do, but I can't get excited about it.

ALTER SET SCHEMA is a relatively near match as well, I think, from a
semantic standpoint.

> The ALTER EXTENSION syntax will
> be a lot more self-contained, with all of it one part of the grammar
> and one part of the documentation.  And you could even allow multiple
> objects:

> ALTER EXTENSION extension_name ADD object-description [, ...];

> Which might be handy.

Hmm, that's an interesting thought.  It'd require rather more
refactoring of the grammar and the parsetree representation than I care
to get into right now, but that could be a foreseeable extension in
future.  On the other hand, it's not *that* exciting, and if multi ADD
isn't supported in the very first version then probably nobody will ever
want to rely on it in extension scripts.

I'm still finding that the "document in one place" angle is the most
compelling argument to me.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [GENERAL] Issues with generate_series using integer boundaries
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extensions versus pg_upgrade