Re: [PATCH] Generalized JSON output functions - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: [PATCH] Generalized JSON output functions
Date
Msg-id CACACo5RU7DD5_k=YbuKgX0i3Bk5Vm8ey-hpnf-Tw_AgXKOKGxw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Generalized JSON output functions  (Ryan Pedela <rpedela@datalanche.com>)
Responses Re: [PATCH] Generalized JSON output functions
List pgsql-hackers
<p dir="ltr">On Jul 17, 2015 12:23 AM, "Ryan Pedela" <<a
href="mailto:rpedela@datalanche.com">rpedela@datalanche.com</a>>wrote:<br /> ><br /> > On Thu, Jul 16, 2015 at
11:51AM, Robert Haas <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>> wrote:<br /> >><br
/>>> I don't understand these issues in great technical depth, but if<br /> >> somebody is arguing that
it'sOK for PostgreSQL to be difficult to use<br /> >> for a certain category of user for several years until the
next<br/> >> language rev becomes mainstream, then I disagree.  The fact that<br /> >> somebody wrote a
patchto try to solve a problem means that the thing<br /> >> in question is a problem for at least that one
user. If he's the only<br /> >> one, maybe we don't need to care all that much.  If his needs are<br /> >>
representativeof a significant user community, we should not turn our<br /> >> backs on that community,
regardlessof whether we like the patch he<br /> >> wrote, and regardless of how well we are meeting the needs of
other<br/> >> communities (like node.js users).<br /> ><br /> ><br /> > I completely agree. However we
aren'ttalking 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
implementerscan fix Javascript.<br /> ><br /> > Here is the current user flow of reading numerics from Postgres
andthen doing some math with them in Javascript.<br /> ><br /> > 1. SELECT json<br /> > 2. Use json-bignum [1]
moduleor custom JSON parser to correctly parse numerics.<br /> > 3. Perform addition, subtraction, etc of numerics
usingeither custom numeric math library or an existing library such as bigdecimal.js [2].<br /> ><br /> > Here is
theuser flow if this patch is accepted.<br /> ><br /> > 1. SELECT json with quoting flags set<br /> > 2.
Customparser to find numeric strings within JSON and convert them into numerics. This is easy if JSON is simple, but
maybe difficult with a very complex JSON.<br /> > 3. Perform addition, subtraction, etc of numerics using either
customnumeric math library or an existing library such as bigdecimal.js [2].<br /> ><br /> > It is almost the
exactsame user flow so what is the point?<p dir="ltr">In my case there's no select: we're running this in the context
ofa logical decoding plugin.<p dir="ltr">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
wouldactually make more sense to use big numbers module only at the point where you have the need for special handling,
notto parse the whole input in a nonstandard way.<p dir="ltr">But the clients that are unaware of big numbers or don't
careabout them shouldn't be *forced* to use external modules for parsing json.<p dir="ltr">> This patch makes
Postgrescore more complex<p dir="ltr">Yes, it does. But, that was not the purpose, obviously. :-)<p dir="ltr">>
whilenot really solving the problem in Javascript.<p dir="ltr">It still allows for less risk of silent data corruption
onthe js side.<p dir="ltr">--<br /> Alex 

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Retrieve the snapshot's LSN
Next
From: Florent Guiliani
Date:
Subject: Re: Retrieve the snapshot's LSN