Joseph Adams 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 s/he wants)
> json_to_b
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane wrote:
> Petr Jelinek 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
Tom Lane wrote:
Robert Haas 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 the javascript null.
r
On Tue, Apr 6, 2010 at 2:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane 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,
Robert Haas writes:
> On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane 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 validation (and perhaps canonicalizatio
On Tue, Apr 6, 2010 at 1:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane 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.
>
>>
Robert Haas writes:
> On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane 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 see no reason to suppose that a
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane wrote:
> Petr Jelinek 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
On Tue, Apr 6, 2010 at 11:05 AM, Alvaro Herrera
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 of malloc and fr
Petr Jelinek 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 with '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 plac
On Mon, Apr 5, 2010 at 11:50 PM, Joseph Adams
wrote:
> 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',
Dne 6.4.2010 7:57, Joseph Adams napsal(a):
On Tue, Apr 6, 2010 at 1:00 AM, Petr Jelinek 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' be SQL's NULL. For
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 'nu
On Mon, Apr 5, 2010 at 11:50 PM, Joseph Adams
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.
...Robert
--
Sent via
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, bu
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 da
On Sat, Apr 3, 2010 at 8:59 AM, Joseph Adams 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
> support comments, some
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 c
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 c
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 (sa
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,
robertmh...@gmail.com (Robert Haas) writes:
> On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus 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 ac
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 i
On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus 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 Postgres which al
> 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 pg
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
Dimitri Fontaine writes:
> Tom Lane 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.
Tom Lane 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 is that it's po
On Mon, Mar 29, 2010 at 2:23 PM, David E. Wheeler 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 matter how spif
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.
Perh
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 Mon, Mar 29, 2010 at 12:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
>> 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
Robert Haas writes:
> On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
> 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 because it doesn't have to link to an
>> e
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
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
Hi,
Joseph Adams 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, single-file, simple-as-c
2010/3/29 Andrew Dunstan :
> Robert Haas wrote:
>> On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
>> 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 ke
On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
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 think"s . I'll be sure to use tags in
> the future :-)
FWIW, I don't care at all whe
On Sun, Mar 28, 2010 at 5:19 PM, Robert Haas wrote:
> On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
> 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 XML does).
>
> Why? I'm not saying y
On Sun, Mar 28, 2010 at 8:33 PM, Robert Haas wrote:
> On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander 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 fo
Andrew Dunstan wrote:
Robert Haas wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander
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
Robert Haas wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander 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 t
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander 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 the only feasibl
On Sun, Mar 28, 2010 at 7:36 PM, Tom Lane wrote:
> Andrew Dunstan 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
>
On Sun, Mar 28, 2010 at 7:36 PM, Tom Lane wrote:
> Andrew Dunstan 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
>
Andrew Dunstan 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. We will *not* be
Tom Lane wrote:
Andrew Dunstan 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 specific
Andrew Dunstan 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, and in
> prac
Robert Haas wrote:
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
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.
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
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.
+1 for text.
> Now my
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 probably be way too ambitious a
project for a newbie
52 matches
Mail list logo
