Re: Add CREATE support to event triggers

From: Jim Nasby <jim(at)nasby(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE support to event triggers
Date: 2014-01-09 22:17:24
Message-ID: 52CF1FF4.8070706@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/9/14, 11:58 AM, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)com> wrote:
>
>>> Hmm. This seems like a reasonable thing to do, except that I would like
>>> the "output" to always be the constant, and have some other way to
>>> enable the clause or disable it. With your "present" boolean:
>>> so
>>>
>>> "if_not_exists": {"output": "IF NOT EXISTS",
>>> "present": true/false}
>>
>> Why not:
>>
>> "if_not_exists": true/false
>
> Yeah, that's another option. If we do this, though, the expansion
> function would have to know that an "if_not_exist" element expands to IF
> NOT EXISTS. Maybe that's okay. Right now, the expansion function is
> pretty stupid, which is nice.

Yeah, the source side of this will always have to understand the nuances of every command; it'd be really nice to not burden the other side with that as well. The only downside I see is a larger JSON output, but meh.

Another advantage is if you really wanted to you could modify the output formatting in the JSON doc to do something radically different if so inclined...
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-01-09 22:26:48 Re: array_length(anyarray)
Previous Message Greg Stark 2014-01-09 22:09:46 Re: Planning time in explain/explain analyze