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