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: