On Fri, Jan 4, 2019 at 6:23 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> 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.
Yeah. The fact that a concurrent refresh currently does DELETE+INSERT
rather than UPDATE is currently an implementation detail. If you
allow users to hook up triggers to the inserts, then suddenly it's no
longer an implementation detail: it is a user-visible behavior that
can't be changed in the future without breaking backward
compatibility.
> Triggers should generally refer to user-facing commands. Could you not
> make a trigger on REFRESH itself?
I'm not sure that would help with the use case... but that seems like
something to think about, especially if it could use the transition
table machinery somehow.
> > 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.
Yeah.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
