Dne 6.4.2010 7:57, Joseph Adams napsal(a):
On Tue, Apr 6, 2010 at 1:00 AM, Petr Jelinekpjmo...@pjmodos.net wrote:
Not really sure about this myself, but keep in mind that NULL has special
meaning in SQL.
To me, the most logical approach is to do the obvious thing: make
JSON's 'null'
Joseph Adams escribió:
http://constellationmedia.com/~funsite/static/json-0.0.2.tar.bz2
My json.c is now 1161 lines long, so I can't quite call it small anymore.
Just noticed you don't check the return value of malloc and friends.
How do you intend to handle that? There are various places
Petr Jelinek pjmo...@pjmodos.net writes:
Dne 6.4.2010 7:57, Joseph Adams napsal(a):
To me, the most logical approach is to do the obvious thing: make
JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
NULLs in it and converting the result set to JSON would yield a
structure
On Tue, Apr 6, 2010 at 11:05 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Joseph Adams escribió:
http://constellationmedia.com/~funsite/static/json-0.0.2.tar.bz2
My json.c is now 1161 lines long, so I can't quite call it small anymore.
Just noticed you don't check the return value
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
Dne 6.4.2010 7:57, Joseph Adams napsal(a):
To me, the most logical approach is to do the obvious thing: make
JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
NULLs
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To me, what this throws into question is not so much whether JSON null
should equate to SQL NULL (it should), but whether it's sane to accept
atomic values.
With this, I disagree. I
On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To me, what this throws into question is not so much whether JSON null
should equate to SQL NULL (it should), but
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Oh. If they're not the same, then the problem is easily dodged, but
then what *is* a JSON null?
I assume we're going to treat JSON much like XML: basically text, but
with some
On Tue, Apr 6, 2010 at 2:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Oh. If they're not the same, then the problem is easily dodged, but
then what *is* a JSON null?
I assume we're
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
With this, I disagree. I see no reason to suppose that a JSON NULL
and an SQL NULL are the same thing.
Oh. If they're not the same, then the problem is easily dodged, but
then what *is* a JSON null?
Probably the same as
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
Dne 6.4.2010 7:57, Joseph Adams napsal(a):
To me, the most logical approach is to do the obvious thing: make
JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
NULLs
Joseph Adams joeyadams3.14...@gmail.com writes:
Perhaps there could be conversion functions. E.g.:
Yeah, that's what I was thinking about.
json_to_string('hello') yields 'hello'
json_to_number('3.14159') yields '3.14159' as text
(it is up to the user to cast it to the number type
Another JSON strictness issue: the JSON standard (
http://www.ietf.org/rfc/rfc4627.txt ) states that JSON text can only
be an array or object. However, my implementation currently accepts
any valid value. Thus, '3', 'hello', 'true', 'false', and 'null'
are all accepted by my implementation, but
On Mon, Apr 5, 2010 at 11:50 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
In my opinion, we should accept an atomic value as valid JSON content.
That seems right to me.
Also, should we go even further and accept key:value pairs by themselves? :
'key:value'::JSON
Definitely not.
Dne 6.4.2010 5:50, Joseph Adams napsal(a):
Another JSON strictness issue: the JSON standard (
http://www.ietf.org/rfc/rfc4627.txt ) states that JSON text can only
be an array or object. However, my implementation currently accepts
any valid value. Thus, '3', 'hello', 'true', 'false', and
I've been wondering whether the JSON datatype should be strict or conservative.
For one, there's strict JSON (following the exact specification).
Then there's more conservative JSON variants. Some JSON parsers
support comments, some support invalid number formats (e.g. '3.' or
'+5'), etc..
The
On Sat, Apr 3, 2010 at 8:59 AM, Joseph Adams joeyadams3.14...@gmail.com wrote:
I've been wondering whether the JSON datatype should be strict or
conservative.
For one, there's strict JSON (following the exact specification).
Then there's more conservative JSON variants. Some JSON parsers
Mike Rylander wrote:
Here's my idea: the datatype should only allow strict JSON, but there
should be a function that accepts a liberal format, cleans it up to
make it strict JSON, and converts it to JSON. I think making strict
JSON the default makes the most sense because:
* Inputs to the
On Apr 1, 2010, at 9:34 PM, Petr Jelinek wrote:
I ended up reinventing the wheel and writing another JSON library:
http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
This is a first release, and it doesn't really have a name besides
json. It's very similar to cJSON, except
Dne 1.4.2010 5:39, Joseph Adams napsal(a):
I ended up reinventing the wheel and writing another JSON library:
http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
This is a first release, and it doesn't really have a name besides
json. It's very similar to cJSON, except it is
robertmh...@gmail.com (Robert Haas) writes:
On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus j...@agliodbs.com wrote:
I'd think that you could get quite a long ways on this, at least doing
something like dbslayer without *necessarily* needing to do terribly
much work inside the DB engine.
I ended up reinventing the wheel and writing another JSON library:
http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
This is a first release, and it doesn't really have a name besides
json. It's very similar to cJSON, except it is (sans unknown bugs)
more reliable, more correct,
joeyadams3.14...@gmail.com (Joseph Adams) writes:
I introduced myself in the thread Proposal: access control jails (and
introduction as aspiring GSoC student), and we discussed jails and
session-local variables. But, as Robert Haas suggested, implementing
variable support in the backend would
I'd think that you could get quite a long ways on this, at least doing
something like dbslayer without *necessarily* needing to do terribly
much work inside the DB engine.
There's actually an HTTP framework tool for Postgres which already does
something of the sort. It was introduced at
On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus j...@agliodbs.com wrote:
I'd think that you could get quite a long ways on this, at least doing
something like dbslayer without *necessarily* needing to do terribly
much work inside the DB engine.
There's actually an HTTP framework tool for
Robert Haas wrote:
While it might be interesting to have/find/write a tool that puts an
HTTP/JSON layer around the DB connection, it's pretty much entirely
unrelated to the proposed project of creating a json type with
PostgreSQL analagous to the xml type we already have, which is what
the OP
Hi,
Joseph Adams joeyadams3.14...@gmail.com writes:
As for reinventing the wheel, I'm in the process of writing yet
another JSON implementation simply because I didn't find the other
ones I looked at palatable.
Even this one (ANSI C, MIT Licenced)?
cJSON -- An ultra-lightweight, portable,
On sön, 2010-03-28 at 23:24 -0400, Joseph Adams wrote:
Thus, here's an example of how (in my opinion) character sets and such
should be handled in the JSON code:
Suppose the client's encoding is UTF-16, and the server's encoding is
Latin-1. When JSON is stored to the database:
1. The
Robert Haas wrote:
I feel pretty strongly that the data should be stored in the database
in the format in which it will be returned to the user - any
conversion which is necessary should happen on the way in. I am not
100% sure to what extent we should attempt to canonicalize the input
and to
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
My reasoning for It should be built-in is:
* It would be nice to have a built-in serialization format that's
available by default.
* It might be a little faster
On Mon, Mar 29, 2010 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
My reasoning for It should be built-in is:
* It would be nice to have a built-in serialization
On 3/28/10 8:52 PM, Hitoshi Harada wrote:
There's another choice, called BSON.
http://www.mongodb.org/display/DOCS/BSON
I've not researched it yet deeply, it seems reasonable to be stored in
databases as it is invented for MongoDB.
I wouldn't take that for granted. The MongoDB project
On Mar 29, 2010, at 9:02 AM, Tom Lane wrote:
If this is going to end up being one fairly small C file implementing
a spec that is not a moving target, I'd vote against depending on an
external library instead, no matter how spiffy and license-compatible
the external library might be.
Perhaps
On Mon, Mar 29, 2010 at 2:23 PM, David E. Wheeler da...@kineticode.com wrote:
On Mar 29, 2010, at 9:02 AM, Tom Lane wrote:
If this is going to end up being one fairly small C file implementing
a spec that is not a moving target, I'd vote against depending on an
external library instead, no
Tom Lane t...@sss.pgh.pa.us writes:
If this is going to end up being one fairly small C file implementing
a spec that is not a moving target, I'd vote against depending on an
external library instead, no matter how spiffy and license-compatible
the external library might be.
My understanding
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
If this is going to end up being one fairly small C file implementing
a spec that is not a moving target, I'd vote against depending on an
external library instead, no matter how spiffy and license-compatible
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I'm wondering whether the internal representation of JSON should be
plain JSON text, or some binary code that's easier to traverse and
whatnot. For the sake of code size, just keeping it in text is
probably best.
Robert Haas wrote:
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I'm wondering whether the internal representation of JSON should be
plain JSON text, or some binary code that's easier to traverse and
whatnot. For the sake of code size, just keeping it in
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I think you need to assume that the encoding will be the server
encoding, not UTF-8. Although others on this list are better
qualified to speak to that than I am.
The trouble is that JSON is defined to be specifically Unicode,
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I think you need to assume that the encoding will be the server
encoding, not UTF-8. Although others on this list are better
qualified to speak to that than I am.
The trouble is that JSON is
Andrew Dunstan and...@dunslane.net writes:
Here's another thought. Given that JSON is actually specified to consist
of a string of Unicode characters, what will we deliver to the client
where the client encoding is, say Latin1? Will it actually be a legal
JSON byte stream?
No, it won't.
On Sun, Mar 28, 2010 at 7:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Here's another thought. Given that JSON is actually specified to consist
of a string of Unicode characters, what will we deliver to the client
where the client encoding is, say
On Sun, Mar 28, 2010 at 7:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Here's another thought. Given that JSON is actually specified to consist
of a string of Unicode characters, what will we deliver to the client
where the client encoding is, say
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander mrylan...@gmail.com wrote:
In practice, every parser/serializer I've used (including the one I
helped write) allows (and, often, forces) any non-ASCII character to
be encoded as \u followed by a string of four hex digits.
Is it correct to say that
Robert Haas wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander mrylan...@gmail.com wrote:
In practice, every parser/serializer I've used (including the one I
helped write) allows (and, often, forces) any non-ASCII character to
be encoded as \u followed by a string of four hex digits.
Andrew Dunstan wrote:
Robert Haas wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander mrylan...@gmail.com
wrote:
In practice, every parser/serializer I've used (including the one I
helped write) allows (and, often, forces) any non-ASCII character to
be encoded as \u followed by a
On Sun, Mar 28, 2010 at 8:33 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander mrylan...@gmail.com wrote:
In practice, every parser/serializer I've used (including the one I
helped write) allows (and, often, forces) any non-ASCII character to
be
On Sun, Mar 28, 2010 at 5:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Now my thoughts and opinions on the JSON parsing/unparsing itself:
It should be built-in, rather than relying on an external library
(like
On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I apologize; I was just starting the conversation with some of my
ideas to receive feedback. I didn't want people to have to wade
through too many I thinks . I'll be sure to use opinion tags in
the future :-)
2010/3/29 Andrew Dunstan and...@dunslane.net:
Robert Haas wrote:
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I'm wondering whether the internal representation of JSON should be
plain JSON text, or some binary code that's easier to traverse and
whatnot.
50 matches
Mail list logo
