On Thu, Jan 9, 2014 at 5:17 PM, Jim Nasby <j...@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
>>> <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
