Re: [PATCH] Logical decoding of TRUNCATE - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [PATCH] Logical decoding of TRUNCATE
Date
Msg-id 31773cc5-3b29-1740-e7d2-dc48e80a06ce@2ndquadrant.com
Whole thread Raw
In response to Re: [PATCH] Logical decoding of TRUNCATE  (Marco Nenciarini <marco.nenciarini@2ndquadrant.it>)
Responses Re: [PATCH] Logical decoding of TRUNCATE
List pgsql-hackers
On 23/01/18 18:19, Marco Nenciarini wrote:
> Il 23/01/18 18:13, Petr Jelinek ha scritto:
>> 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.
>>
> 
> No it doesn't. The following code in worker.c prevents that.
> 
> 
> +     /*
> +      * Even if we used CASCADE on the upstream master we explicitly
> +      * default to replaying changes without further cascading.
> +      * This might be later changeable with a user specified option.
> +      */
> +     cascade = false;

Ah, that's pretty ugly, why don't we just use DROP_RESTRICT always
instead of this (keeping the comment). Unless you plan to make it option
as part of this patch, the current coding is confusing.

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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative
Next
From: Peter Eisentraut
Date:
Subject: Re: pgsql: Improve scripting language in pgbench