Re: [PATCH] Generalized JSON output functions

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Ryan Pedela <rpedela(at)datalanche(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, hlinnaka <hlinnaka(at)iki(dot)fi>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [PATCH] Generalized JSON output functions
Date: 2015-07-17 12:20:05
Message-ID: CACACo5RU7DD5_k=YbuKgX0i3Bk5Vm8ey-hpnf-Tw_AgXKOKGxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jul 17, 2015 12:23 AM, "Ryan Pedela" <rpedela(at)datalanche(dot)com> wrote:
>
> On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
wrote:
>>
>> I don't understand these issues in great technical depth, but if
>> somebody is arguing that it's OK for PostgreSQL to be difficult to use
>> for a certain category of user for several years until the next
>> language rev becomes mainstream, then I disagree. The fact that
>> somebody wrote a patch to try to solve a problem means that the thing
>> in question is a problem for at least that one user. If he's the only
>> one, maybe we don't need to care all that much. If his needs are
>> representative of a significant user community, we should not turn our
>> backs on that community, regardless of whether we like the patch he
>> wrote, and regardless of how well we are meeting the needs of other
>> communities (like node.js users).
>
>
> I completely agree. However we aren't talking about a usability problem
with Postgres. We are actually talking about a usability problem with
Javascript, and trying to implement a band-aid for it with Postgres.
Javascript doesn't support large numbers, it just doesn't. There is nothing
the Postgres community can do about that. Only the ECMAscript standards
committee and implementers can fix Javascript.
>
> Here is the current user flow of reading numerics from Postgres and then
doing some math with them in Javascript.
>
> 1. SELECT json
> 2. Use json-bignum [1] module or custom JSON parser to correctly parse
numerics.
> 3. Perform addition, subtraction, etc of numerics using either custom
numeric math library or an existing library such as bigdecimal.js [2].
>
> Here is the user flow if this patch is accepted.
>
> 1. SELECT json with quoting flags set
> 2. Custom parser to find numeric strings within JSON and convert them
into numerics. This is easy if JSON is simple, but may be difficult with a
very complex JSON.
> 3. Perform addition, subtraction, etc of numerics using either custom
numeric math library or an existing library such as bigdecimal.js [2].
>
> It is almost the exact same user flow so what is the point?

In my case there's no select: we're running this in the context of a
logical decoding plugin.

The all safeguarding idea that is enabled by this patch is that if the
client *expects* big numbers *and* it needs to perform arithmetic on them,
it'll have the special handling anyway. And IMO, it would actually make
more sense to use big numbers module only at the point where you have the
need for special handling, not to parse the whole input in a nonstandard
way.

But the clients that are unaware of big numbers or don't care about them
shouldn't be *forced* to use external modules for parsing json.

> This patch makes Postgres core more complex

Yes, it does. But, that was not the purpose, obviously. :-)

> while not really solving the problem in Javascript.

It still allows for less risk of silent data corruption on the js side.

--
Alex

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florent Guiliani 2015-07-17 12:31:30 Re: Retrieve the snapshot's LSN
Previous Message Robert Haas 2015-07-17 12:11:49 Re: Retrieve the snapshot's LSN