Re: [PATCH] Generalized JSON output functions

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

> On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> The thing is - it's not only about whitespace, otherwise I would probably
>>> not bother with the generic interface. For my original problem, there is
>>> simply no way to do this correctly in an extension w/o copying over all of
>>> the logic from json.c, which I have to do right now, would rather not.
>>>
>> I am sorry - we are talking about JSON, not about any styled document. I
>> disagree, so it has not be implemented as extension - the backport of JSON
>> support is a extension.
>>
>
> Hm... I'm having a hard time making sense of that statement, sorry.
>
> To reiterate: for my problem, that is escaping numerics that can
> potentially overflow[1] under ECMAScript standard, I want to be able to
> override the code that outputs the numeric converted to string. There is
> no way in current implementation to do that *at all*, short of copying all
> the code involved in producing JSON output and changing it at certain
> points. One could try re-parsing JSON instead, but that doesn't actually
> solve the issue, because type information is lost forever at that point.
>
> The whitespace unification was a mere side-effect of the original effort
> on this patch.
>

The dynamic type change is some what I would not to do in database, really
:)

If you afraid about overflow, then convert numeric to string immediately -
in this case, the client have to support both variant - so immediate cast
should not be a problem.

Anyway this check on max number should be implemented in our JSON(b) out
functions (as warning?).

Regards

Pavel

>
> --
> Best regards,
> Alex
>
> [1]
> http://stackoverflow.com/questions/307179/what-is-javascripts-highest-integer-value-that-a-number-can-go-to-without-losin
>
>