On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan and...@dunslane.net 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
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 may
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan and...@dunslane.net 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
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 design.
On Mar 13, 2013, at 5:17 AM, Robert Haas robertmh...@gmail.com 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
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 and...@dunslane.net
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
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 and...@dunslane.net
wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan and...@dunslane.net 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
On 03/13/2013 01:50 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan and...@dunslane.net 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
On Mar 13, 2013, at 10:59 AM, Andrew Dunstan and...@dunslane.net 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.
On 03/13/2013 12:40 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 5:17 AM, Robert Haas robertmh...@gmail.com 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
On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler da...@justatheory.com 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
On 03/08/2013 09:39 PM, Robert Haas wrote:
On Thu, Mar 7, 2013 at 2:48 PM, David E. Wheeler da...@justatheory.com 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
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 da...@justatheory.com
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
On Mar 8, 2013, at 1:01 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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
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
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 da...@justatheory.com wrote:
In the spirit of being liberal about what we accept but strict about what we
store, it seems to me
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan and...@dunslane.net 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
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 da...@justatheory.com wrote:
In the spirit of being liberal about what we accept but strict about what we
store, it seems to me
On 03/08/2013 04:28 PM, David E. Wheeler wrote:
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan and...@dunslane.net 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
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 and...@dunslane.net wrote:
Here's what rfc2119 says about that wording:
4. SHOULD NOT This phrase, or the phrase NOT RECOMMENDED mean that
there may
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
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
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
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
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, not MUST.
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}'::json;
27 matches
Mail list logo
