On Jul25, 2011, at 07:35 , Joey Adams wrote:
On Mon, Jul 25, 2011 at 1:05 AM, Joey Adams joeyadams3.14...@gmail.com
wrote:
Should we mimic IEEE floats and preserve -0 versus +0 while treating
them as equal? Or should we treat JSON floats like numeric and
convert -0 to 0 on input? Or should
On Jul25, 2011, at 02:03 , Florian Pflug wrote:
On Jul25, 2011, at 00:48 , Joey Adams wrote:
Should we follow the JavaScript standard for rendering numbers (which
my suggestion approximates)? Or should we use the shortest encoding
as Florian suggests?
In the light of the above, consider my
On Jul24, 2011, at 05:14 , Robert Haas wrote:
On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
Interesting. This leads to a couple more questions:
* Should the JSON data type (eventually) have an equality operator?
+1.
+1.
* Should the JSON input
On Sat, Jul 23, 2011 at 11:14 PM, Robert Haas robertmh...@gmail.com wrote:
I doubt you're going to want to reinvent TOAST, ...
I was thinking about making it efficient to access or update
foo.a.b.c.d[1000] in a huge JSON tree. Simply TOASTing the varlena
text means we have to unpack the entire
On Jul25, 2011, at 00:48 , Joey Adams wrote:
On Sun, Jul 24, 2011 at 2:19 PM, Florian Pflug f...@phlo.org wrote:
On Jul24, 2011, at 05:14 , Robert Haas wrote:
On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
... Fortunately, JSON's definition of a
number is its
On Sun, Jul 24, 2011 at 2:19 PM, Florian Pflug f...@phlo.org wrote:
The downside being that we'd then either need to canonicalize in
the equality operator, or live with either no equality operator or
a rather strange one.
It just occurred to me that, even if we sort object members, texteq
On Mon, Jul 25, 2011 at 1:05 AM, Joey Adams joeyadams3.14...@gmail.com wrote:
Should we mimic IEEE floats and preserve -0 versus +0 while treating
them as equal? Or should we treat JSON floats like numeric and
convert -0 to 0 on input? Or should we do something else? I think
converting -0
Also, should I forbid the escape \u (in all database encodings)?
Pros:
* If \u is forbidden, and the server encoding is UTF-8, then
every JSON-wrapped string will be convertible to TEXT.
* It will be consistent with the way PostgreSQL already handles text,
and with the decision to use
On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
Interesting. This leads to a couple more questions:
* Should the JSON data type (eventually) have an equality operator?
+1.
* Should the JSON input function alphabetize object members by key?
I think it would
I think I've decided to only allow escapes of non-ASCII characters
when the database encoding is UTF8. For example, $$\u2013$$::json
will fail if the database encoding is WIN1252, even though WIN1252 can
encode U+2013 (EN DASH). This may be somewhat draconian, given that:
* SQL_ASCII can
On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
On another matter, should the JSON type guard against duplicate member
keys? The JSON RFC says The names within an object SHOULD be
unique, meaning JSON with duplicate members can be considered valid.
JavaScript
On 23/07/11 01:12, Robert Haas wrote:
On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
On another matter, should the JSON type guard against duplicate member
keys? The JSON RFC says The names within an object SHOULD be
unique, meaning JSON with duplicate members
On Fri, Jul 22, 2011 at 7:16 PM, Jan Urbański wulc...@wulczer.org wrote:
On 23/07/11 01:12, Robert Haas wrote:
On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
On another matter, should the JSON type guard against duplicate member
keys? The JSON RFC says The
On Jul23, 2011, at 01:12 , Robert Haas wrote:
On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
On another matter, should the JSON type guard against duplicate member
keys? The JSON RFC says The names within an object SHOULD be
unique, meaning JSON with duplicate
On Jul23, 2011, at 00:04 , Joey Adams wrote:
I think I've decided to only allow escapes of non-ASCII characters
when the database encoding is UTF8. For example, $$\u2013$$::json
will fail if the database encoding is WIN1252, even though WIN1252 can
encode U+2013 (EN DASH). This may be
On Fri, Jul 22, 2011 at 7:12 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm. That's tricky. I lean mildly toward throwing an error as being
more consistent with the general PG philosophy.
I agree. Besides, throwing an error on duplicate keys seems like the
most logical thing to do. The
On Jul20, 2011, at 06:40 , Joey Adams wrote:
On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas robertmh...@gmail.com wrote:
Thanks for the input. I'm leaning in this direction too. However, it
will be a tad tricky to implement the conversions efficiently, ...
I'm a bit confused, because I
On Wed, Jul 20, 2011 at 6:49 AM, Florian Pflug f...@phlo.org wrote:
Hm, I agree that we need to handle \u escapes in JSON input.
We won't ever produce them during output though, right?
We could, to prevent transcoding errors if the client encoding is
different than the server encoding (and
On Mon, Jul 18, 2011 at 7:36 PM, Florian Pflug f...@phlo.org wrote:
On Jul19, 2011, at 00:17 , Joey Adams wrote:
I suppose a simple solution would be to convert all escapes and
outright ban escapes of characters not in the database encoding.
+1. Making JSON work like TEXT when it comes to
Excerpts from Joey Adams's message of mar jul 19 21:03:15 -0400 2011:
On Mon, Jul 18, 2011 at 7:36 PM, Florian Pflug f...@phlo.org wrote:
On Jul19, 2011, at 00:17 , Joey Adams wrote:
I suppose a simple solution would be to convert all escapes and
outright ban escapes of characters not in
Forwarding because the mailing list rejected the original message.
-- Forwarded message --
From: Joey Adams joeyadams3.14...@gmail.com
Date: Tue, Jul 19, 2011 at 11:23 PM
Subject: Re: Initial Review: JSON contrib modul was: Re: [HACKERS]
Another swing at JSON
To: Alvaro Herrera
...@gmail.com
Date: Tue, Jul 19, 2011 at 11:23 PM
Subject: Re: Initial Review: JSON contrib modul was: Re: [HACKERS]
Another swing at JSON
To: Alvaro Herrera alvhe...@commandprompt.com
Cc: Florian Pflug f...@phlo.org, Tom Lane t...@sss.pgh.pa.us, Robert
Haas robertmh...@gmail.com, Bernd Helmle
.
---
-- Forwarded message --
From: Joey Adams joeyadams3.14...@gmail.com
Date: Tue, Jul 19, 2011 at 11:23 PM
Subject: Re: Initial Review: JSON contrib modul was: Re: [HACKERS]
Another swing at JSON
To: Alvaro Herrera alvhe...@commandprompt.com
Cc: Florian Pflug f...@phlo.org, Tom Lane t
On Tue, Jul 19, 2011 at 9:03 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
On Mon, Jul 18, 2011 at 7:36 PM, Florian Pflug f...@phlo.org wrote:
On Jul19, 2011, at 00:17 , Joey Adams wrote:
I suppose a simple solution would be to convert all escapes and
outright ban escapes of characters not
On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas robertmh...@gmail.com wrote:
Thanks for the input. I'm leaning in this direction too. However, it
will be a tad tricky to implement the conversions efficiently, ...
I'm a bit confused, because I thought what I was talking about was not
doing any
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I'll try to submit a revised patch within the next couple days.
Sorry this is later than I said.
I addressed the issues covered in
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
I'm having a really hard time figuring out how the JSON module should
handle non-Unicode character sets.
But, again, why not just forget about transcoding and define it as
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
I'm having a really hard time figuring out how the JSON module should
handle non-Unicode character sets.
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, could the \u problem be finessed by leaving such escapes in
source form?
Yes, it could. However, it doesn't solve the problem of comparison
(needed for member lookup), which requires canonicalizing the strings
to be
On Jul19, 2011, at 00:17 , Joey Adams wrote:
I suppose a simple solution would be to convert all escapes and
outright ban escapes of characters not in the database encoding.
+1. Making JSON work like TEXT when it comes to encoding issues
makes this all much simpler conceptually. It also avoids
On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I'll try to submit a revised patch within the next couple days.
Sorry this is later than I said.
I addressed the issues covered in the review. I also fixed a bug
where \u0022 would become , which is invalid JSON,
On 7/4/11 7:22 PM, Joseph Adams wrote:
I'll try to submit a revised patch within the next couple days.
So? New patch?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
--On 18. Juni 2011 12:29:38 +0200 Bernd Helmle maili...@oopsware.de wrote:
Similar problems occur with a couple other modules I tried (hstore,
intarray).
Hmm, works for me. Seems you have messed up your installation in some way
(build against current -HEAD but running against a 9.1?).
I'm
Thanks for reviewing my patch!
On Mon, Jul 4, 2011 at 7:10 AM, Bernd Helmle maili...@oopsware.de wrote:
+comment = 'data type for storing and manipulating JSON content'
I'm not sure, if manipulating is a correct description. Maybe i missed it,
but i didn't see functions to manipulate JSON
34 matches
Mail list logo
