On 07/15/2015 10:52 AM, Robert Haas wrote:
On Mon, Jul 13, 2015 at 10:46 AM, Ryan Pedela <rped...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
