Re: Add CREATE support to event triggers
От | Robert Haas |
---|---|
Тема | Re: Add CREATE support to event triggers |
Дата | |
Msg-id | CA+TgmoZpRocmAbr0zp3mocAvTWAeeyovLrp0fYZfm_TfrDTyqQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add CREATE support to event triggers (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
On Thu, Jan 9, 2014 at 5:17 PM, Jim Nasby <jim@nasby.net> wrote: > 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@2ndquadrant.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... Yeah. I wasn't necessarily objecting to the way Alvaro did it, just asking why he did it that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: