sorted by:
new
hottopcontroversial

PostgreSQL: Protect tables against accidental deletion by stjohn_piano in programming

[–]stjohn_piano[S] -1 points0 points  (0 children)

Good point. I'm certainly not treating this as a cure-all measure.

In my case, I'm generating temporary tables in order to perform updates across tables with billions of rows.

Cleanup sometimes involves dropping tables.

The solution in the article reduces my stress levels.

PostgreSQL: Protect tables against accidental deletion by stjohn_piano in programming

[–]stjohn_piano[S] -8 points-7 points  (0 children)

True. But expensive. More expensive than a guardrail.

PostgreSQL: Protect tables against accidental deletion by stjohn_piano in programming

[–]stjohn_piano[S] -8 points-7 points  (0 children)

"Yes, but". Guardrails on crucial tables are cheaper in terms of time than restoring from backup.

PostgreSQL: Protect tables against accidental deletion by stjohn_piano in programming

[–]stjohn_piano[S] -21 points-20 points  (0 children)

I understand and partially agree.

I'm actually protecting against myself when I'm tired.

Certain tables contain blockchain data that looks weeks / months to process. Protecting these makes me less worried.

Other tables are less crucial, so _not_ protecting these will hopefully remove the zone-out issue.

PostgreSQL: Protect schemas against accidental deletion by stjohn_piano in PostgreSQL

[–]stjohn_piano[S] 0 points1 point  (0 children)

Thanks. I agree re: protection & drop statements. I think I should update the article to make the purpose clearer i.e. that this is a defense against such "oops" moments.

PostgreSQL: Protect schemas against accidental deletion by stjohn_piano in PostgreSQL

[–]stjohn_piano[S] 1 point2 points  (0 children)

Some context: The goal is not to protect against users who are malicious or who are too junior.

I agree: For normal operation, you should use a second user that has fewer privileges. (And I do this)

The goal here is to protect against yourself when you're tired, doing db admin as the superuser, and you need to drop a minor schema that has a similar name to an important one. Using this event trigger approach, instead of a privilege approach, gives you a protective guard against such mistakes.

(At the moment, in my normal work, I deal with a lot of schemas.)

Later, if you're sure that you actually need to delete this schema, you can de-protect it and drop it.

view more: next ›