On 2015-04-02 12:05:13 -0400, Robert Haas wrote: > On Wed, Mar 25, 2015 at 3:21 PM, Ryan Pedela <rped...@datalanche.com> wrote: > > On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers