On 28/12/2018 08:43, Mitar wrote:
> A summary of the patch: This patch enables adding AFTER triggers (both
> ROW and STATEMENT) on materialized views. They are fired when doing
> REFRESH MATERIALIZED VIEW CONCURRENTLY for rows which have changed.
What bothers me about this patch is that it subtly changes what a
trigger means. It currently means, say, INSERT was executed on this
table. You are expanding that to mean, a row was inserted into this
table -- somehow.
Triggers should generally refer to user-facing commands. Could you not
make a trigger on REFRESH itself?
> Triggers are not fired if you call REFRESH without CONCURRENTLY. This
> is based on some discussion on the mailing list because implementing
> it for without CONCURRENTLY would require us to add logic for firing
> triggers where there was none before (and is just an efficient heap
> swap).
This is also a problem, because it would allow bypassing the trigger
accidentally.
Moreover, consider that there could be updatable materialized views,
just like there are updatable normal views. And there could be triggers
on those updatable materialized views. Those would look similar but
work quite differently from what you are proposing here.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
