PATCH: Add hstore_to_json()
in [PgSql]
|
From: "David E. Wheeler" on 3 Jan 2010 22:21 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]')::text; > 1 > ----- > b No, because 'b' isn't valid JSON. So if we want an interface that returns scalars, they can't be JSON. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 3 Jan 2010 22:26 On Sun, Jan 3, 2010 at 11:00 AM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > Hitoshi Harada wrote: >> 2010/1/3 Andrew Dunstan <andrew(a)dunslane.net>: >>> 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. >> Because what we need may be another wheel nobody has already invented. >> I don't deny to use one of external libraries but don't like to decide >> specification by their specifications. > OK, we really need to stop being abstract and say what operations we want. > I think the minimal functionality I'd want is: > > convert record to JSON > convert JSON to record > extract a value, or set of values, from JSON > composition of JSON > > Now all the libraries I have looked at (briefly) would require some code to > provide for those, possibly quite a bit of code, but that doesn't mean we > should just start from scratch and write our own JSON parser too. I think this is really vastly overkill. The set of operations I think we need is more like: - given a JSON value, tell me if it's a string, number, object, array, true, false, or null - given a JSON object, give me the list of member names (error if it's not a hash) - given a JSON object, give me the member named x (error if it's not a hash) - given a JSON array, give me the upper bound (error if it's not an array) - given a JSON array, give me the element at offset x (error if it's not an array) What you're talking about may or may not be useful and someone may or may not want to implement it, but insisting that we have to have it for the first version of a json type seems to me to be setting the bar quite a bit higher than necessary. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Hitoshi Harada on 4 Jan 2010 03:35 2010/1/4 David E. Wheeler <david(a)kineticode.com>: > 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]')::text; >> 1 >> ----- >> b > > No, because 'b' isn't valid JSON. So if we want an interface that returns scalars, they can't be JSON. AFAIK string value can be parsed as JSON. At least my local v8 shell answers: > JSON.stringify({"foo": {"bar": ["a", "b", "c"]}}) {"foo":{"bar":["a","b","c"]}} > JSON.stringify("b") "b" Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 4 Jan 2010 23:18 On Sun, Jan 3, 2010 at 1:51 PM, David E. Wheeler <david(a)kineticode.com> 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?). > >> extract a value, or set of values, from JSON >> composition of JSON > > There's a lot of functionality in hstore that I'd like to see. It'd make sense to use the same operators for the same operations. I think I'd start with hstore as a basic spec. David, 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 add it unless we add a json type first. Thoughts? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 4 Jan 2010 23:36
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 add it unless we add a > json type first. Not me, too much on my plate, and not enough C knowledge to be efficient. Agreed on "Returned with Feedback." Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |