From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ryan Pedela <rpedela(at)datalanche(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: deparsing utility commands |
Date: | 2015-04-02 16:05:13 |
Message-ID: | CA+TgmobgyYRM1-Ja0MmKKa9idcsFqqxACzpGKd-3z60B6Xg3Vw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 25, 2015 at 3:21 PM, Ryan Pedela <rpedela(at)datalanche(dot)com> wrote:
> On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-04-02 16:11:08 | Re: deparsing utility commands |
Previous Message | Robert Haas | 2015-04-02 16:00:52 | Re: varlena.c hash_any() and hash_uint32() calls require DatumGetUInt32() |