On 28 September 2014 02:22, Shai Berger <[email protected]> wrote:
> Upon reading the docs, I was a little surprised to see that in terms of
> triggers etc, the operation is always considered an INSERT. I would expect it
> to be considered an insert for BEFORE INSERT or INSTEAD OF INSERT triggers,
> but if conflict resolution turns it into an UPDATE, I'd expect to see it
> handled as an UPDATE from that point on (definitely INSTEAD OF UPDATE and
> AFTER
> UPDATE triggers, maybe even BEFORE UPDATE). That is the semantics we have now
> (this is a general remark, not particulary Django-oriented; Django does not
> use triggers on PG as far as I know, and only uses them elsewhere to implement
> serial keys).
Hmm, good thinking.
So it should act like this?
BEFORE INSERT triggers fire
if CONFLICT then
{
BEFORE UPDATE triggers fire
perform UPDATE
AFTER UPDATE triggers fire
}
else
{
perform INSERT
AFTER INSERT triggers fire
}
INSTEAD OF triggers would fire on views only, so would be shown in the
above instead of the before triggers
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CA%2BU5nMJbr-b09Ed6AxTeU44TNZF53_NDYc0DuV-RtcQqqQ7u3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
