2015-07-11 19:57 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> On Jul 11, 2015 6:19 PM, "Pavel Stehule" <pavel.steh...@gmail.com> wrote: > > > > > > > > 2015-07-11 18:02 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> > >> On Fri, Jul 10, 2015 at 5:16 PM, Pavel Stehule <pavel.steh...@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
