Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?
Дата
Msg-id d505e15c-8573-f856-7c91-35c4674ae91c@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2017/04/17 14:46, Robert Haas wrote:
> On Sun, Apr 16, 2017 at 11:58 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> By the way, Petr said in the other thread that it could be made a no-op
>> (presumably without requiring IF NOT EXISTS) on the grounds that
>> membership of table in publication is "soft object" or "property" rather
>> than real object.
> 
> I don't find that argument terribly convincing.
> 
> The nearest parallel that we have for this is probably:
> 
> ALTER EXTENSION name ADD member_object;
> ALTER EXTENSION name DROP member_object;
> 
> I would guess this ought to work similarly.

Hmm, it does make sense to mock this behavior.

create extension dummy;
create table foo ();
alter extension dummy add table foo;
alter extension dummy add table foo;
ERROR:  table foo is already a member of extension "dummy"

Thanks,
Amit




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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] Variable substitution in psql backtick expansion