Re: [PATCH] Generalized JSON output functions

On 07/15/2015 10:52 AM, Robert Haas wrote:
> On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela <rpedela@datalanche.com> wrote:
>> As far as large numbers in JSON, I think Postgres is doing the right thing
>> and should not be changed. It is Javascript that is stupid here, and I don't
>> think it is wise to add something to core just because one client does
>> stupid things with large numbers. In addition, ES7 is introducing "value
>> types" which will hopefully solve the large number problem in Javascript.
> FWIW, I don't agree.  If it's not easy to read the JSON that
> PostgreSQL generates using JavaScript, then a lot of people are just
> going to give up on doing it, and IMO that would be sad.  Telling
> people that they have to parse the JSON using some parser other than
> the one built into their JavaScript engine, whack it around, and then
> render it as text and parse it again is not really an acceptable
> answer.  The reason why the logical decoding stuff allows multiple
> output formats is because Andres, quite correctly, foresaw that
> different people would need different output formats.  He could have
> designed that system to output only one output format and just said,
> everybody's got to read and parse this, but that would have been slow.
> Instead, he tried to set things up so that you could get the output in
> the format that was most convenient for your client, whatever that is.
> On this thread, we're back-pedaling from that idea: sorry, you can get
> JSON output, but if you want JSON output that will be properly
> interpreted by your JSON parser, you can't have that.  Regardless of
> the details of this particular patch, I can't endorse that approach.
> If we want people to use our software, we need to meet them where they
> are at, especially when we are only (IIUC) talking about inserting a
> few extra quotation marks.
>

The question for me is where is the best place to transform the data. 
The approach take was both invasive and broken. The approach I 
suggested, reparsing and transforming it in the logical decoder, would 
be both fairly simple and completely noninvasive. If someone gives me a 
test for what is an acceptable number for JS processors, I bet I could 
write a transformation function in an hour or two, and in a hundred 
lines or so. I admit that I probably have more experience doing this 
than anyone else, but the parser API was designed to be fairly simple, 
and I believe it is.

cheers

andrew