Re: [PATCH] Generalized JSON output functions - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [PATCH] Generalized JSON output functions
Date
Msg-id CAFj8pRDmtJ9S+-+9_fF8jb_EqAm5C-ESEv9M1=fLwUFKwjAFxw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Generalized JSON output functions  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: [PATCH] Generalized JSON output functions
List pgsql-hackers


2015-07-11 19:57 GMT+02:00 Shulgin, Oleksandr <oleksandr.shulgin@zalando.de>:

On Jul 11, 2015 6:19 PM, "Pavel Stehule" <pavel.stehule@gmail.com> wrote:
>
>
>
> 2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr <oleksandr.shulgin@zalando.de>:
>>
>> On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>>
>>>>  
>>>> Well, one could call it premature pessimization due to dynamic call overhead.
>>>>
>>>> IMO, the fact that json_out_init_context() sets the value callback to json_out_value is an implementation detail, the other parts of code should not rely on.  And for the Explain output, there definitely going to be *some* code between context initialization and output callbacks: these are done in a number of different functions.
>>>
>>>
>>> Again - it is necessary? Postgres still use modular code, not OOP code. I can understand the using of this technique, when I need a possibility to change behave. But these function are used for printing JSON, not printing any others.
>>
>>
>> No, it's not strictly necessary.
>>
>> For me it's not about procedural- vs. object- style, but rather about being able to override/extend the behavior consistently.  And for that I would prefer that if I override the value callback in a JSON output context, that it would be called for every value being printed, not only for some of them.
>
>
> please, can me show any real use case? JSON is JSON, not  art work.

To quote my first mail:

The motivation behind this to be able to produce specially-crafted JSON in a logical replication output plugin, such that numeric (and bigint) values are quoted.  This requirement, in turn, arises from the fact that JavaScript specification, which is quite natural to expect as a consumer for this JSON data, allows to silently drop significant digits when converting from string to number object.

I believe this is a well-known problem and I'm aware of a number of tricks that might be used to avoid it, but none of them seems to be optimal from my standpoint.

I can also imagine this can be used to convert date/time to string differently, or adding indentation depending on the depth in object hierarchy, etc.

There is simple rule - be strict on output and tolerant on input. If I understand to sense of this patch - the target is one same format of JSON documents - so there are no space for any variability.
 

> Still I don't see any value of this.

Huh? Why then do you spend time on review?

I am thinking so general json functions has sense, but I partially disagree with your implementation.

Regards

Pavel
 

pgsql-hackers by date:

Previous
From: "Shulgin, Oleksandr"
Date:
Subject: Re: [PATCH] Generalized JSON output functions
Next
From: Tom Lane
Date:
Subject: TABLESAMPLE patch is really in pretty sad shape