PATCH: Add hstore_to_json()
in [PgSql]
|
From: "David E. Wheeler" on 31 Dec 2009 11:00 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 validation and encoding handling and smooth > integration with said languages. What about access to various parts of a JSON data structure? Or is that just asking for too much trouble up-front? 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: Andrew Dunstan on 31 Dec 2009 11:12 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 get >> out of it are input validation and encoding handling and smooth >> integration with said languages. >> > > What about access to various parts of a JSON data structure? Or is that just asking for too much trouble up-front? > > > IMNSHO it's essential. I think Peter's approach of ignoring this requirement is extremely shortsighted. cheers andrew -- 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 31 Dec 2009 16:28 On Thu, Dec 31, 2009 at 11:12 AM, Andrew Dunstan <andrew(a)dunslane.net> 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 >>> operators doesn't sound useless to me. The features I would like to get >>> out of it are input validation and encoding handling and smooth >>> integration with said languages. >>> >> >> What about access to various parts of a JSON data structure? Or is that >> just asking for too much trouble up-front? > > IMNSHO it's essential. I think Peter's approach of ignoring this requirement > is extremely shortsighted. I could go either way on this. As a practical matter, we probably shouldn't pick a library that is only a validator without any ability to manipulate the data structure. And as a further practical matter, that done, it's probably not that much work to expose whatever other functionality that library provides. But I would not go to the extent of saying that we should try to figure out from first principles what functionality we want to include and then make it a requirement that the chosen library must support all of those things. That seems like a recipe for failure... 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 feature otherwise?". Does anyone have any real-world experience with any of the JSON C libraries? ....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: Andrew Dunstan on 31 Dec 2009 17:35 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 > feature otherwise?". > > Does anyone have any real-world experience with any of the JSON C libraries? > > > I do not, but I see that YAJL <http://lloyd.github.com/yajl/> is now in Fedora, and has a BSDish license, so maybe that's a good place to start. Maybe someone would like to try designing an API which could sit atop that. Then we would not need to speculate based on principle. I'd rather we use a library we can pull in like libxml than have to import the source and have to keep in sync with the upstream. cheers andrew -- 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: Tom Lane on 31 Dec 2009 17:37
Robert Haas <robertmhaas(a)gmail.com> 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 the > feature otherwise?". Count me as -1 for "sucking in" any sizable amount of code for this. I do not wish to be on the hook to maintain something like that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |