Re: [PATCH] Logical decoding of TRUNCATE

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Logical decoding of TRUNCATE
Date: 2018-01-23 17:13:09
Message-ID: ffb116ef-a072-2b9b-dd92-e288dbfa0f6c@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

On 23/01/18 15:38, Marco Nenciarini wrote:
> Il 22/01/18 23:18, Petr Jelinek ha scritto:
>> On 22/01/18 19:45, Petr Jelinek wrote:
>>
>> Actually on second look, I don't like the new boolean parameter much.
>> I'd rather we didn't touch the input list and always close only
>> relations opened inside the ExecuteTruncateGuts().
>>
>> It may mean more list(s) but the current interface is still not clean.
>>
>
> Now ExecuteTruncateGuts unconditionally closes the relations that it
> opens. The caller has now always the responsibility to close the
> relations passed with the explicit_rels list.

This looks good.

>
> Version 15 attached.
>

I see you still do CASCADE on the subscriber though.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marco Nenciarini 2018-01-23 17:19:36 Re: [PATCH] Logical decoding of TRUNCATE
Previous Message Marco Nenciarini 2018-01-23 14:38:45 Re: [PATCH] Logical decoding of TRUNCATE

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2018-01-23 17:19:36 Re: [PATCH] Logical decoding of TRUNCATE
Previous Message Peter Eisentraut 2018-01-23 17:08:37 Re: Handling better supported channel binding types for SSL implementations