PATCH: Add hstore_to_json()
in [PgSql]
|
From: Robert Haas on 29 Dec 2009 21:14 On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut <peter_e(a)gmx.net> 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 <david(a)kineticode.com> 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? > > At the moment it would be more of a placeholder, because if we later > decide to add full-blown JSON-constructing and -destructing > functionality, it would be difficult to change the signatures of all the > existing functionality. 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 postpone adding any more functions that generate json output until such time as we have a real type for it. I wouldn't feel too bad about changing the output type of EXPLAIN (FORMAT JSON) from text to json in 8.6, because it's relatively difficult to be depending on that for anything very important. It's much easier to be depending on something like this, and changing it later could easily break working applications. Anyone have an interest in taking a crack at this? ....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 30 Dec 2009 12:38 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 postpone adding any more functions that > generate json output until such time as we have a real type for it. I > wouldn't feel too bad about changing the output type of EXPLAIN > (FORMAT JSON) from text to json in 8.6, because it's relatively > difficult to be depending on that for anything very important. It's > much easier to be depending on something like this, and changing it > later could easily break working applications. +1 > Anyone have an interest in taking a crack at this? There are a bunch of C libraries listed on http://www.json.org/. Perhaps one has a suitable license and clean enough implementation to be used? 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 30 Dec 2009 12:53 On Wed, Dec 30, 2009 at 12:38 PM, David E. Wheeler <david(a)kineticode.com> 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 the new type. If not, I'm >> inclined to say that we should postpone adding any more functions that >> generate json output until such time as we have a real type for it. I >> wouldn't feel too bad about changing the output type of EXPLAIN >> (FORMAT JSON) from text to json in 8.6, because it's relatively >> difficult to be depending on that for anything very important. It's >> much easier to be depending on something like this, and changing it >> later could easily break working applications. > > +1 > >> Anyone have an interest in taking a crack at this? > > There are a bunch of C libraries listed on http://www.json.org/. Perhaps one has a suitable license and clean enough implementation to be used? 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. 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 are commonly packaged already? ....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 30 Dec 2009 13:23 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 >> are commonly packaged already? >> > > I doubt that they have similar interfaces, so we'd probably have to rely on one. I'd probably favor embedding, personally, it's less work for admins. > > > 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, for example. How will we extract values from a JSON object? How will we be able to set values inside them? In ECMAScript it's not a problem, because the objects returned are just like any other objects, but that's not the case here. These are the sorts of questions we need to answer before we look at any implementation details, I think. 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 30 Dec 2009 14:23
On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan <andrew(a)dunslane.net> 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, for example. How will we extract values from a JSON object? How > will we be able to set values inside them? In ECMAScript it's not a problem, > because the objects returned are just like any other objects, but that's not > the case here. These are the sorts of questions we need to answer before we > look at any implementation details, I think. I think the idea that Peter was proposing was to start by creating a type that doesn't necessarily have a lot of operators or functions associated with it, with the thought of adding those later. It would still need to validate the input, of course. Anyhow, that might be a bad way to approach the problem, but I think that's how we got here. ....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 |