## 1.1.0 (2020-07-21)
### Feature
- Added "Referencing" construct for statement-level triggers. [Wes Kendall, 20d958e]
The ``pgtrigger.Referencing`` construct allows one to reference
transition tables in statement-level triggers.
- Added statement-level triggers. [Wes Kendall, c0cc365]
django-pgtrigger now has a "level" construct for specifying
row and statement-level triggers. All triggers default to being
row-level triggers.
### Trivial
- Support the "INSTEAD OF" construct for views on SQL triggers. [Wes Kendall, 79f9d54]
- Updated docs and added a quick start section [Wes Kendall, 9ce7b29]
## 1.0.1 (2020-06-29)
### Trivial
- Updated README and updated with the latest public django app template. [Wes Kendall, 001ef68]
## 1.0.0 (2020-06-27)
### Api-Break
- Initial release of django-pgtrigger. [Wes Kendall, 1f737f0]
``django-pgtrigger`` provides primitives for configuring
`Postgres triggers <https://www.postgresql.org/docs/current/sql-createtrigger.html>`__
on Django models.
Models can be decorated with `pgtrigger.register` and supplied with
`pgtrigger.Trigger` objects. These will automatically be installed after
migrations. Users can use Django idioms such as ``Q`` and ``F`` objects to
declare trigger conditions, alleviating the need to write raw SQL for a large
amount of use cases.
``django-pgtrigger`` comes built with some derived triggers for expressing
common patterns. For example, `pgtrigger.Protect` can protect operations
on a model, such as deletions or updates (e.g. an append-only model). The
`pgtrigger.Protect` trigger can even target protecting operations on
specific updates of fields (e.g. don't allow updates if ``is_active`` is
``False`` on a model). Another derived trigger, `pgtrigger.SoftDelete`,
can soft-delete models by setting a field to ``False`` when a deletion
happens on the model.