Re: Suggestion: provide a "TRUNCATE PARTITION" command - Mailing list pgsql-general

From Michael Lewis
Subject Re: Suggestion: provide a "TRUNCATE PARTITION" command
Date
Msg-id CAHOFxGqp0MSfzLP14CbiazoDazJEQFFeQLYiDDxiryOSg+gR0g@mail.gmail.com
Whole thread Raw
In response to Re: Suggestion: provide a "TRUNCATE PARTITION" command  (Thomas Kellerer <shammat@gmx.net>)
Responses Re: Suggestion: provide a "TRUNCATE PARTITION" command
List pgsql-general


On Fri, Jan 8, 2021 at 10:12 AM Thomas Kellerer <shammat@gmx.net> wrote:
Michael Lewis schrieb am 08.01.2021 um 17:47:
>      > For me, it seems too easily error prone such that a single typo in
>      > the IN clause may result in an entire partition being removed that
>      > wasn't supposed to be targeted.
>
>     I don't see how this is more dangerous then:
>
>           delete from base_table
>           where partition_key in (...);
>
>     which would serve the same purpose, albeit less efficient.
>
>
> Delete has a rollback option, and you can dry-run to see impacted rows effectively. Truncate does not.

TRUNCATE can be rolled back as well.

My apologies. There are other concerns with concurrent transactions, but you are correct that it can be rolled back.

Still, no feedback on the effect that a truncate call is having on the DB and may be doing more than intended fairly easily. I am not in the hackers group so I couldn't say this feature would not be implemented. It just seems unlikely given the philosophies of that group.

pgsql-general by date:

Previous
From: legrand legrand
Date:
Subject: Re: Suggestion: provide a "TRUNCATE PARTITION" command
Next
From: Jack Orenstein
Date:
Subject: Finding memory corruption in an extension