Nico Williams <nico@cryptonector.com> writes:
> On Fri, Sep 15, 2017 at 02:19:29PM -0500, Nico Williams wrote:
>> On Fri, Sep 15, 2017 at 11:26:08AM -0700, Andres Freund wrote:
>>> I think you should also explain why that's a desirable set of
>>> semantics.
> Now, why is this desirable: atomicity.
> The client/user can no longer add statements to the transaction,
> therefore now (commit-time) is a good time to run a procedure that
> can *atomically* examine the totatility of the changes made by the
> user.
I do not really understand this claim. The argument for a commit trigger
seems to be exactly "I want to be the last thing that happens in the
transaction". But as soon as you have two of them, one of them is not
going to be the last thing. Maybe you could address that by requiring
the triggers to be read-only, but then it doesn't seem like a very useful
feature. If there can be only one, maybe it's a usable feature or maybe
not, but I'm inclined to think that CREATE TRIGGER is a pretty poor API
for such a definition. Triggers are generally expected to be objects
you can create any number of.
Another question is exactly how you're going to "examine the totality of
the transaction's changes"; a trigger, per se, isn't going to know *any*
of what the transaction did let alone all of it. We have some features
like transition tables, but they're not accessible after end of statement;
and they're pretty useless in the face of DDL too. It's going to be hard
to produce a very credible use-case without a lot of work to expose that
information somehow.
(Some closely related work is being done for logical decoding, btw.
I wonder which use-cases for this might be satisfied by having a logical
decoding plug-in watching the WAL output.)
> Commit triggers also allow one to record transaction boundaries, and
> NOTIFY listeners less frequently than if one did a NOTIFY in normal
> for-each-row/statement triggers.
Um, NOTIFY already collapses duplicate notifications per-transaction.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers