<p dir="ltr">On Jul 11, 2015 6:19 PM, "Pavel Stehule" <<a
href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>wrote:<br /> ><br /> ><br /> ><br /> >
2015-07-1118:02 GMT+02:00 Shulgin, Oleksandr <<a
href="mailto:oleksandr.shulgin@zalando.de">oleksandr.shulgin@zalando.de</a>>:<br/> >><br /> >> On Fri,
Jul10, 2015 at 5:16 PM, Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>
wrote:<br/> >>>><br /> >>>> <br /> >>>> Well, one could call it premature
pessimizationdue to dynamic call overhead.<br /> >>>><br /> >>>> 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
shouldnot rely on. And for the Explain output, there definitely going to be *some* code between context initialization
andoutput callbacks: these are done in a number of different functions.<br /> >>><br /> >>><br />
>>>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.<br/> >><br /> >><br /> >> No, it's not strictly necessary.<br /> >><br /> >> For
meit'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
becalled for every value being printed, not only for some of them.<br /> ><br /> ><br /> > please, can me show
anyreal use case? JSON is JSON, not art work.<p dir="ltr">To quote my first mail:<p dir="ltr">The motivation behind
thisto be able to produce specially-crafted JSON in a logical replication output plugin, such that numeric (and bigint)
valuesare quoted. This requirement, in turn, arises from the fact that JavaScript specification, which is quite
naturalto expect as a consumer for this JSON data, allows to silently drop significant digits when converting from
stringto number object.<p dir="ltr">I believe this is a well-known problem and I'm aware of a number of tricks that
mightbe used to avoid it, but none of them seems to be optimal from my standpoint.<p dir="ltr">I can also imagine this
canbe used to convert date/time to string differently, or adding indentation depending on the depth in object
hierarchy,etc.<p dir="ltr">> Still I don't see any value of this.<p dir="ltr">Huh? Why then do you spend time on
review?<br/>