Re: [HACKERS] PATCH: Add hstore_to_json()

On Jan 4, 2010, at 8:18 PM, Robert Haas wrote: > Is this something you are planning to work on for the 2010-01-15 > CommitFest? If not, I think we should go ahead and mark the patch > which was the original subject of this thread "Returned with > Feedback", as it does not seem to make sense to ad

Re: [HACKERS] PATCH: Add hstore_to_json()

On Sun, Jan 3, 2010 at 1:51 PM, David E. Wheeler wrote: > On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote: > >> I think the minimal functionality I'd want is: >> >>   convert record to JSON >>   convert JSON to record > > With caveats as to dealing with nested structures (can a record be an > at

Re: [HACKERS] PATCH: Add hstore_to_json()

2010/1/4 David E. Wheeler : > On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote: > >> That sounds good and seems possible, as far as operator returns JSON >> always. Perhaps every JSON fetching returns JSON even if the result >> would be a number. You can cast it. >> >>   % SELECT ('{"foo":{"bar":["

Re: [HACKERS] PATCH: Add hstore_to_json()

On Sun, Jan 3, 2010 at 11:00 AM, Andrew Dunstan wrote: > Hitoshi Harada wrote: >> 2010/1/3 Andrew Dunstan : >>> Hitoshi Harada wrote: A question: Isn't there no possibility that we have our own implementation to handle JSON (i.e. no use of external libraries)? >>> Why should we reinvent

Re: [HACKERS] PATCH: Add hstore_to_json()

On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote: > That sounds good and seems possible, as far as operator returns JSON > always. Perhaps every JSON fetching returns JSON even if the result > would be a number. You can cast it. > > % SELECT ('{"foo":{"bar":["a","b","c"]}}' -> '["foo"][1]')::te

Re: [HACKERS] PATCH: Add hstore_to_json()

Hitoshi Harada wrote: 2010/1/4 David E. Wheeler : On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote: We allow composites as fields. The biggest mismatch in the type model is probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular, AIUI. Cool, that sounds

Re: [HACKERS] PATCH: Add hstore_to_json()

2010/1/4 David E. Wheeler : > On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote: > >> We allow composites as fields. The biggest mismatch in the type model is >> probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular, >> AIUI. > > Cool, that sounds right. Does it mean you sho

Re: [HACKERS] PATCH: Add hstore_to_json()

On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote: > We allow composites as fields. The biggest mismatch in the type model is > probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular, > AIUI. Cool, that sounds right. > OK, but hstores are flat, unlike JSON. We need some way

Re: [HACKERS] PATCH: Add hstore_to_json()

David E. Wheeler wrote: On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote: I think the minimal functionality I'd want is: convert record to JSON convert JSON to record With caveats as to dealing with nested structures (can a record be an attribute of a record?). We allow

Re: [HACKERS] PATCH: Add hstore_to_json()

On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote: > I think the minimal functionality I'd want is: > > convert record to JSON > convert JSON to record With caveats as to dealing with nested structures (can a record be an attribute of a record?). > extract a value, or set of values, from

Re: [HACKERS] PATCH: Add hstore_to_json()

Hitoshi Harada wrote: 2010/1/3 Andrew Dunstan : Hitoshi Harada wrote: A question: Isn't there no possibility that we have our own implementation to handle JSON (i.e. no use of external libraries)? Why should we reinvent a wheel someone else has already invented? This is wha

Re: [HACKERS] PATCH: Add hstore_to_json()

2010/1/3 Andrew Dunstan : > > > Hitoshi Harada wrote: >> >> A question: Isn't there no possibility that we have our own >> implementation to handle JSON (i.e. no use of external libraries)? >> >> >> > > Why should we reinvent a wheel someone else has already invented? This is > what shared librarie

Re: [HACKERS] PATCH: Add hstore_to_json()

Hitoshi Harada wrote: A question: Isn't there no possibility that we have our own implementation to handle JSON (i.e. no use of external libraries)? Why should we reinvent a wheel someone else has already invented? This is what shared libraries are all about. cheers andrew -- Sent v

Re: [HACKERS] PATCH: Add hstore_to_json()

2010/1/3 Peter Eisentraut : > On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote: >> Mine for one :-). Quite apart from any other reason I would expect it to >> make indexing parts of the JSON more tractable. Say we use it to store a >> web session object, which is a natural enough use. I migh

Re: [HACKERS] PATCH: Add hstore_to_json()

On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote: > Mine for one :-). Quite apart from any other reason I would expect it to > make indexing parts of the JSON more tractable. Say we use it to store a > web session object, which is a natural enough use. I might well want to > find or modif

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan writes: > Peter Eisentraut wrote: >> Whose requirement is it? I'm not ignoring it, but so far no one has >> actually said that it is a requirement and why. > Mine for one :-). I think there are a couple of interacting factors here. We are not likely to want to go far out of our

Re: [HACKERS] PATCH: Add hstore_to_json()

Peter Eisentraut wrote: IMNSHO it's essential. I think Peter's approach of ignoring this requirement is extremely shortsighted. Whose requirement is it? I'm not ignoring it, but so far no one has actually said that it is a requirement and why. Mine for one :-). Quite apart from an

Re: [HACKERS] PATCH: Add hstore_to_json()

On tor, 2009-12-31 at 11:12 -0500, Andrew Dunstan wrote: > > David E. Wheeler wrote: > > On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote: > > > > > >> I think the primary use will be to load a JSON value into Perl or Python > >> and process it there. So a json type that doesn't have any in

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan writes: >> Does anyone have any real-world experience with any of the JSON C libraries? > > I do not, but I see that YAJL is now in > Fedora, and has a BSDish license It's there in debian too, unstable and testing, and should be there on the next sta

Re: [HACKERS] PATCH: Add hstore_to_json()

On Thu, Dec 31, 2009 at 5:37 PM, Tom Lane wrote: > Robert Haas writes: >> Anyhow, that brings me back to the question I asked upthread, which is >> "Can/should we suck one of these libraries into our code base (and if >> so, which?) or do we need to add an analogue of --with-libxml so that >> we

Re: [HACKERS] PATCH: Add hstore_to_json()

Robert Haas writes: > Anyhow, that brings me back to the question I asked upthread, which is > "Can/should we suck one of these libraries into our code base (and if > so, which?) or do we need to add an analogue of --with-libxml so that > we can link against an external library if present and omit

Re: [HACKERS] PATCH: Add hstore_to_json()

Robert Haas wrote: Anyhow, that brings me back to the question I asked upthread, which is "Can/should we suck one of these libraries into our code base (and if so, which?) or do we need to add an analogue of --with-libxml so that we can link against an external library if present and omit the f

Re: [HACKERS] PATCH: Add hstore_to_json()

On Thu, Dec 31, 2009 at 11:12 AM, Andrew Dunstan wrote: > David E. Wheeler wrote: >> On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote: >>> >>> I think the primary use will be to load a JSON value into Perl or Python >>> and process it there.  So a json type that doesn't have any interesting >>>

Re: [HACKERS] PATCH: Add hstore_to_json()

David E. Wheeler wrote: On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote: I think the primary use will be to load a JSON value into Perl or Python and process it there. So a json type that doesn't have any interesting operators doesn't sound useless to me. The features I would like to

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote: > I think the primary use will be to load a JSON value into Perl or Python > and process it there. So a json type that doesn't have any interesting > operators doesn't sound useless to me. The features I would like to get > out of it are input

Re: [HACKERS] PATCH: Add hstore_to_json()

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Doesn't seem insurmountable, though, just one more thing to think > about as we're having this conversation. Someone else will need to > weigh in on this point though, as I don't use JSON in a way that would > make anything beyond validation

Re: [HACKERS] PATCH: Add hstore_to_json()

On ons, 2009-12-30 at 13:23 -0500, Andrew Dunstan wrote: > I'd like to see at > least the outline of an API before we go any further. JSON is, shall > we > say, lightly specified, and doesn't appear to have any equivalent to > XPath and friends, for example. How will we extract values from a > J

Re: [HACKERS] PATCH: Add hstore_to_json()

On ons, 2009-12-30 at 12:53 -0500, Robert Haas wrote: > It looks like they are all very permissive, though I wonder what the > legal effect of a license clause that the software be used for Good > and not Evil might be. It's not without issues, apparently: http://grep.be/blog/en/computer/legal/go

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 30, 2009 at 2:26 PM, Andrew Dunstan wrote: > Robert Haas wrote: >> On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan >> wrote: >>> I think we are getting the cart way before the horse. I'd like to see at >>> least the outline of an API before we go any further. JSON is, shall we >>> say

Re: [HACKERS] PATCH: Add hstore_to_json()

Robert Haas wrote: On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan wrote: I think we are getting the cart way before the horse. I'd like to see at least the outline of an API before we go any further. JSON is, shall we say, lightly specified, and doesn't appear to have any equivalent to XP

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan wrote: > I think we are getting the cart way before the horse. I'd like to see at > least the outline of an API before we go any further. JSON is, shall we say, > lightly specified, and doesn't appear to have any equivalent to XPath and > friends, fo

Re: [HACKERS] PATCH: Add hstore_to_json()

David E. Wheeler wrote: I guess the question is whether we would slurp one of these into our code base, or whether we would add an analog of --with-libxml and provide only a stub implementation when the library is not present. Any opinions? Does anyone know whether any of these implementations

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 30, 2009, at 9:53 AM, Robert Haas wrote: > It looks like they are all very permissive, though I wonder what the > legal effect of a license clause that the software be used for Good > and not Evil might be. Yeah, that might be too restrictive, given that PostgreSQL is used by government a

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 30, 2009 at 12:38 PM, David E. Wheeler wrote: > On Dec 29, 2009, at 6:14 PM, Robert Haas wrote: > >> I've been mulling this over and I think this is a pretty good idea. >> If we could get it done in time for 8.5, we could actually change the >> output type of EXPLAIN (FORMAT JSON) to t

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 29, 2009, at 6:14 PM, Robert Haas wrote: > I've been mulling this over and I think this is a pretty good idea. > If we could get it done in time for 8.5, we could actually change the > output type of EXPLAIN (FORMAT JSON) to the new type. If not, I'm > inclined to say that we should postpo

Re: [HACKERS] PATCH: Add hstore_to_json()

On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut wrote: > On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote: >> On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler >> wrote: >> > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: >> > >> >> Should we create a json type before adding all kin

Re: [HACKERS] PATCH: Add hstore_to_json()

On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan wrote: >> One problem is that there is not a single well-defined mapping between >> these types.  I would say generally that XML and YAML both have more >> types of constructs than JSON.  The obvious ways of translating an >> arbitrary XML document t

Re: [HACKERS] PATCH: Add hstore_to_json()

Robert Haas wrote: On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane wrote: Alvaro Herrera writes: Tom Lane escribió: Well, actually, now that you mention it: how much of a json type would be duplicative of the xml stuff? Would it be sufficient to provide json <-> xml converters an

Re: [HACKERS] PATCH: Add hstore_to_json()

On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut wrote: > On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote: >> On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler >> wrote: >> > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: >> > >> >> Should we create a json type before adding all kin

Re: [HACKERS] PATCH: Add hstore_to_json()

On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote: > On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler > wrote: > > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: > > > >> Should we create a json type before adding all kinds of json formatted > >> data? Or are we content with json as t

Re: [HACKERS] PATCH: Add hstore_to_json()

+1 for such a feature, simply to avoid the need of writing a hstore-parser (which wasn't too bad to write, but it felt unnecessary). Doesn't matter to me if it's hstore-to-json or hstore-to-xml or hstore-to-yaml. Just something that parsers are readily available for. Heck, I wouldn't mind if hs

Re: [HACKERS] PATCH: Add hstore_to_json()

On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane escribió: >>> Well, actually, now that you mention it: how much of a json type would >>> be duplicative of the xml stuff?  Would it be sufficient to provide >>> json <-> xml converters and let the latter type do

Re: [HACKERS] PATCH: Add hstore_to_json()

Alvaro Herrera writes: > Tom Lane escribió: >> Well, actually, now that you mention it: how much of a json type would >> be duplicative of the xml stuff? Would it be sufficient to provide >> json <-> xml converters and let the latter type do all the heavy lifting? >> (If so, this patch ought to b

Re: [HACKERS] PATCH: Add hstore_to_json()

Tom Lane escribió: > Andrew Dunstan writes: > > Tom Lane wrote: > >> [ I can already hear somebody insisting on a yaml type :-( ] > > > Now that's a case where I think a couple of converter functions at most > > should meet the need. > > Well, actually, now that you mention it: how much of a js

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan writes: > Tom Lane wrote: >> [ I can already hear somebody insisting on a yaml type :-( ] > Now that's a case where I think a couple of converter functions at most > should meet the need. Well, actually, now that you mention it: how much of a json type would be duplicative of the

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan wrote: > > > Tom Lane wrote: > > Andrew Dunstan writes: > > > >> You're correct that we don't necessarily need a new type, we could just > >> make it text and have a bunch of operations, but that seems to violate > >> the principle of data type abstraction a bit. > >> >

Re: [HACKERS] PATCH: Add hstore_to_json()

Tom Lane wrote: Andrew Dunstan writes: You're correct that we don't necessarily need a new type, we could just make it text and have a bunch of operations, but that seems to violate the principle of data type abstraction a bit. I think the relevant precedent is that we have an xml

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan writes: > You're correct that we don't necessarily need a new type, we could just > make it text and have a bunch of operations, but that seems to violate > the principle of data type abstraction a bit. I think the relevant precedent is that we have an xml type. While I surely d

Re: [HACKERS] PATCH: Add hstore_to_json()

Robert Haas wrote: On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler wrote: On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: Should we create a json type before adding all kinds of json formatted data? Or are we content with json as text? json_data_type++ What w

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 18, 2009, at 8:51 AM, Robert Haas wrote: > What would that do for us? > > I'm not opposed to it, but it seems like the more important thing > would be to provide functions or operators that can do things like > extract an array, extract a hash key, identify whether something is a > hash, l

Re: [HACKERS] PATCH: Add hstore_to_json()

On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler wrote: > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: > >> Should we create a json type before adding all kinds of json formatted >> data?  Or are we content with json as text? > > json_data_type++ What would that do for us? I'm not oppo

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: > Should we create a json type before adding all kinds of json formatted > data? Or are we content with json as text? json_data_type++ D -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] PATCH: Add hstore_to_json()

On ons, 2009-12-16 at 11:28 -0800, David E. Wheeler wrote: > I just realized that this was easy to do, and despite my complete lack of C > skillz was able to throw this together in a couple of hours. It might be > handy to some, though the possible downsides are: > > * No json_to_hstore(). > * L

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 16, 2009 at 5:58 PM, David E. Wheeler wrote: > On Dec 16, 2009, at 2:45 PM, Robert Haas wrote: > >> I like it.  The regression tests you've added seem to cover a lot of >> cases that aren't really different without covering some that are >> probably worth trying, like multiple key/valu

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 16, 2009, at 2:45 PM, Robert Haas wrote: > I like it. The regression tests you've added seem to cover a lot of > cases that aren't really different without covering some that are > probably worth trying, like multiple key/value pairs. Also, the > comment in the function you've added looks

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 16, 2009 at 2:28 PM, David E. Wheeler wrote: > I just realized that this was easy to do, and despite my complete lack of C > skillz was able to throw this together in a couple of hours. It might be > handy to some, though the possible downsides are: > > * No json_to_hstore(). > * Lea

[HACKERS] PATCH: Add hstore_to_json()

I just realized that this was easy to do, and despite my complete lack of C skillz was able to throw this together in a couple of hours. It might be handy to some, though the possible downsides are: * No json_to_hstore(). * Leads to requests for hstore_to_yaml(), hstore_to_xml(), etc. * Andrew G