Re: deparsing utility commands

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

In response to

Responses

Browse pgsql-hackers by date

  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()