On Fri, Jan 8, 2021 at 10:12 AM Thomas Kellerer <sham...@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.
