TRUNCATE in a few databases effectively drops the table, and recreates it.
If typing in an interactive session usually use a specific user account for it, with minimal set of privileges. And wouldn't have the DROP privilege or any other DDL statement privilege.
DDL would be scripted out, tested and ran using another user account that had only privileges on specific databases it needed.
IIRC (I'm not about to go test it now) DROP TABLE is transactional. But yeah, TRUNCATE is an odd beast. In Postgresql 10:
> TRUNCATE is not MVCC-safe. After truncation, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the truncation occurred. See Section 13.5 for more details.
> TRUNCATE is transaction-safe with respect to the data in the tables: the truncation will be safely rolled back if the surrounding transaction does not commit.
If typing in an interactive session usually use a specific user account for it, with minimal set of privileges. And wouldn't have the DROP privilege or any other DDL statement privilege. DDL would be scripted out, tested and ran using another user account that had only privileges on specific databases it needed.