On 2015-04-02 12:05:13 -0400, Robert Haas wrote:
> On Wed, Mar 25, 2015 at 3:21 PM, Ryan Pedela <rpedela@datalanche.com> wrote:
> > On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera <alvherre@2ndquadrant.com>
> > wrote:
> >> * Should we prohibit DDL from within event triggers?
> >
> > Please don't prohibit DDL unless there is a really, really good reason to do
> > so. I have several use cases in mind for event triggers, but they are only
> > useful if I can perform DDL.
> >
> > For example, I want to create an Elasticsearch FDW and use that to index and
> > search Postgres tables. When a table is created, I am planning to use an
> > event trigger to capture the CREATE event and automatically create a foreign
> > table via the Elasticsearch FDW. In addition, I would add normal triggers to
> > the new table which capture DML and update the foreign table accordingly. In
> > other words, I want to use FDWs and event triggers to automatically sync
> > table DDL and DML to Elasticsearch.
>
> +1. I think that if it's unsafe to run DDL from with event triggers,
> then that might be a sign that it's not safe to run *any* user-defined
> code at that location. I think it's the job of the event trigger to
> make sure that it doesn't assume anything about what may have changed
> while the user-defined code was running.
First of: I don't see a fundamental reason to forbid it, I think it's
just simpler to analyze that way. But I'm unconvinced by that
reasoning. As you know we prohibit executing DDL on some objects in
*lots* of places c.f. CheckTableNotInUse(), without that imo being a
sign of a more fundamental problem.
Greetings,
Andres Freund
