On 03/13/2013 12:40 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 5:17 AM, Robert Haas wrote:
What I think is tricky here is that there's more than one way to
conceptualize what the JSON data type really is. Is it a key-value
store of sorts, or just a way to store text values that meet cert
On Mar 13, 2013, at 10:59 AM, Andrew Dunstan wrote:
>> And my first cut at it won’t descend into sub-objects.
>
>
> The you wouldn't be doing it right. The whole thing about a recursive descent
> parser is that it's, well, recursive.
Right, but it would serve my immediate needs. I have a colu
On 03/13/2013 01:50 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan wrote:
If someone wants functions to enforce a stricter validity check (e.g. via a
check constraint on a domain), or to convert json to a canonical version which
strips out prior keys of the same na
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan wrote:
> If someone wants functions to enforce a stricter validity check (e.g. via a
> check constraint on a domain), or to convert json to a canonical version
> which strips out prior keys of the same name and their associated values,
> then these
On 03/13/2013 12:51 PM, Gavin Flower wrote:
On 14/03/13 02:02, Andrew Dunstan wrote:
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan
wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last insta
On 14/03/13 02:02, Andrew Dunstan wrote:
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan
wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a
key wins
and is actually stored
2.
On Mar 13, 2013, at 5:17 AM, Robert Haas wrote:
> What I think is tricky here is that there's more than one way to
> conceptualize what the JSON data type really is. Is it a key-value
> store of sorts, or just a way to store text values that meet certain
> minimalist syntactic criteria? I had i
On 2013-03-13 20:48:57 +0800, Craig Ringer wrote:
> On 03/13/2013 08:17 PM, Robert Haas wrote:
> > I think Andrew and I had envisioned this as basically a text data type
> > that enforces some syntax checking on its input, hence the current
> > design. But I'm not sure that's the ONLY sensible des
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a key wins
and is actually stored
2. Throw an error when a JSON type has duplica
On 03/13/2013 08:17 PM, Robert Haas wrote:
> I think Andrew and I had envisioned this as basically a text data type
> that enforces some syntax checking on its input, hence the current
> design. But I'm not sure that's the ONLY sensible design.
We're probably stuck with it at this point, but it ma
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan wrote:
>> So my order of preference for the options would be:
>>
>> 1. Have the JSON type collapse objects so the last instance of a key wins
>> and is actually stored
>>
>> 2. Throw an error when a JSON type has duplicate keys
>>
>> 3. Have the acces
On Fri, Mar 08, 2013 at 10:34:20PM +0100, Hannu Krosing wrote:
> On 03/08/2013 10:01 PM, Alvaro Herrera wrote:
>> Hannu Krosing escribi?:
>>> If it does not meet these "semantic" constraints, then it is not
>>> really JSON - it is merely JSON-like.
>> Is it wrong? The standard cited says SHOULD,
On 03/08/2013 06:37 PM, Hannu Krosing wrote:
I suspect that 99.98% of the time we will get valid and unique JS
Object serializations or equivalent as input to json_in()
If we want the getter functions to handle the "loose JSON" to Object
conversion
side assuming our stored JSON can conta
On 03/08/2013 11:03 PM, Andrew Dunstan wrote:
On 03/08/2013 04:42 PM, Andrew Dunstan wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a key
wins and is actually stored
2. Throw an error when a JSON type has duplicat
> Actually, now I think more about it 3 is the best answer. Here's why:
> even the JSON generators can produce JSON with non-unique field names:
+1
Also, I think we should add a json_normalize() function to the TODO list.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent v
On 03/08/2013 04:42 PM, Andrew Dunstan wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a key
wins and is actually stored
2. Throw an error when a JSON type has duplicate keys
3. Have the accessors find the last ins
On 03/08/2013 10:42 PM, Andrew Dunstan wrote:
On 03/08/2013 04:28 PM, David E. Wheeler wrote:
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan wrote:
Here's what rfc2119 says about that wording:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reaso
On 03/08/2013 04:28 PM, David E. Wheeler wrote:
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan wrote:
Here's what rfc2119 says about that wording:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
part
On 03/08/2013 10:01 PM, Alvaro Herrera wrote:
Hannu Krosing escribió:
On 03/08/2013 09:39 PM, Robert Haas wrote:
On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler wrote:
In the spirit of being liberal about what we accept but strict about what we
store, it seems to me that JSON object key uni
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan wrote:
> Here's what rfc2119 says about that wording:
>
> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
> there may exist valid reasons in particular circumstances when the
> particular behavior is acceptable or even useful,
On 03/08/2013 04:01 PM, Alvaro Herrera wrote:
Hannu Krosing escribió:
On 03/08/2013 09:39 PM, Robert Haas wrote:
On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler wrote:
In the spirit of being liberal about what we accept but strict about what we
store, it seems to me that JSON object key un
Well I would much prefer to find out sooner rather than later that there
is a problem, so I would much prefer know I've created a duplicate as
soon as the system can detect it. In general, Postgresql appears much
better at this than MySQL
On 09/03/13 10:01, Alvaro Herrera wrote:
Hannu Krosi
On Mar 8, 2013, at 1:01 PM, Alvaro Herrera wrote:
>> If it does not meet these "semantic" constraints, then it is not
>> really JSON - it is merely JSON-like.
>>
>> this sounds very much like MySQLs decision to support timestamp
>> "-00-00 00:00" - syntactically correct, but semantically wro
Hannu Krosing escribió:
> On 03/08/2013 09:39 PM, Robert Haas wrote:
> >On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler
> >wrote:
> >>In the spirit of being liberal about what we accept but strict about what
> >>we store, it seems to me that JSON object key uniqueness should be enforced
> >>ei
On 03/08/2013 09:39 PM, Robert Haas wrote:
On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler wrote:
In the spirit of being liberal about what we accept but strict about what we
store, it seems to me that JSON object key uniqueness should be enforced either
by throwing an error on duplicate key
On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler wrote:
> In the spirit of being liberal about what we accept but strict about what we
> store, it seems to me that JSON object key uniqueness should be enforced
> either by throwing an error on duplicate keys, or by flattening so that the
> lates
On 03/07/2013 02:48 PM, David E. Wheeler wrote:
This behavior surprised me a bit:
david=# select '{"foo": 1, "foo": 2}'::json;
json
--
{"foo": 1, "foo": 2}
I had expected something more like this:
david=# select '{"foo": 1, "foo": 2}'::js
This behavior surprised me a bit:
david=# select '{"foo": 1, "foo": 2}'::json;
json
--
{"foo": 1, "foo": 2}
I had expected something more like this:
david=# select '{"foo": 1, "foo": 2}'::json;
json
{"fo
28 matches
Mail list logo
