Re: [PATCH] Generalized JSON output functions

2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>
:

> On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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. Still I
don't see any value of this.

>
> Thank you for pointing out the case of Explain format, I've totally
> overlooked it in my first version. Trying to apply the proposed approach
> in the explain printing code led me to reorganize things slightly. I've
> added explicit functions for printing keys vs. values, thus no need to
> expose that key_scalar param anymore. There are now separate before/after
> key and before/after value functions as well, but I believe it makes for a
> cleaner code.
>
> The most of the complexity is still in the code that decides whether or
> not to put spaces (between the values or for indentation) and newlines at
> certain points. Should we decide to unify the style we emit ourselves,
> this could be simplified, while still leaving room for great flexibility if
> overridden by an extension, for example.
>
> Have a nice weekend.
>

you too

Regards

Pavel

> --
> Alex
>
>