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, con
On Jul25, 2011, at 07:35 , Joey Adams wrote:
> On Mon, Jul 25, 2011 at 1:05 AM, Joey Adams
> 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 el
On Mon, Jul 25, 2011 at 1:05 AM, Joey Adams 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 to 0 would be a bad idea
On Sun, Jul 24, 2011 at 2:19 PM, Florian Pflug 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
might not be a
On Jul25, 2011, at 00:48 , Joey Adams wrote:
> On Sun, Jul 24, 2011 at 2:19 PM, Florian Pflug wrote:
>> On Jul24, 2011, at 05:14 , Robert Haas wrote:
>>> On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams
>>> wrote:
... Fortunately, JSON's definition of a
"number" is its decimal syntax, so t
On Sat, Jul 23, 2011 at 11:14 PM, Robert Haas 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 datum to access and u
On Jul24, 2011, at 05:14 , Robert Haas wrote:
> On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams
> 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 function alphabetize
On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams 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 probably be better if i
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 7:12 PM, Robert Haas 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 most compelling reason
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 s
On Jul23, 2011, at 01:12 , Robert Haas wrote:
> On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams
> 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 c
On Fri, Jul 22, 2011 at 7:16 PM, Jan Urbański wrote:
> On 23/07/11 01:12, Robert Haas wrote:
>> On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams
>> wrote:
>>> On another matter, should the JSON type guard against duplicate member
>>> keys? The JSON RFC says "The names within an object SHOULD be
>>>
On 23/07/11 01:12, Robert Haas wrote:
> On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams
> 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 considere
On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams 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 interpreters (the ones I
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 othe
On Wed, Jul 20, 2011 at 6:49 AM, Florian Pflug 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 neither is S
On Jul20, 2011, at 06:40 , Joey Adams wrote:
> On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas 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
On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas 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 conversions in
On Tue, Jul 19, 2011 at 9:03 PM, Joey Adams wrote:
> On Mon, Jul 18, 2011 at 7:36 PM, Florian Pflug 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.
>>
>>
Marc says it is now fixed.
---
>
> >
> > -- Forwarded message --
> > From: Joey Adams
> > 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
> >
om: Joey Adams
> 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
> Cc: Florian Pflug , Tom Lane , Robert
> Haas , Bernd Helmle ,
> Dimitri Fontaine , David Fetter
> , Josh
Forwarding because the mailing list rejected the original message.
-- Forwarded message --
From: Joey Adams
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
Cc: Florian Pflug , Tom
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 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 dat
On Mon, Jul 18, 2011 at 7:36 PM, Florian Pflug 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 encoding i
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 18, 2011 at 3:19 PM, Tom Lane 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 compared.
Here's
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams
>> 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
Robert Haas writes:
> On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams
> 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
> "JSON, if you happen to be using utf-8
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams wrote:
> On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams
> 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
On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams
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, causing an
assertion f
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:
http:
Thanks for reviewing my patch!
On Mon, Jul 4, 2011 at 7:10 AM, Bernd Helmle 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 strings directly,
--On 18. Juni 2011 12:29:38 +0200 Bernd Helmle 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 going to review in th
34 matches
Mail list logo
