Re: [PATCH] Generalized JSON output functions

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

> On Jul 11, 2015 6:19 PM, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >
> >
> >
> > 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.
>
> 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