PATCH: Add hstore_to_json()
in [PgSql]
|
From: Andrew Dunstan on 30 Dec 2009 14:26 Robert Haas wrote: > 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. > > > That does not at all seem like a good way to go. Until we know what operations we want to support we have no idea which library to use. We can not assume that they will all support what we want to do. 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:30 On Wed, Dec 30, 2009 at 2:26 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > Robert Haas wrote: >> 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. >> > That does not at all seem like a good way to go. Until we know what > operations we want to support we have no idea which library to use. We can > not assume that they will all support what we want to do. Well that is a bit of a problem, yes... 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 particularly relevant. ....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: Peter Eisentraut on 31 Dec 2009 03:55 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/good_not_evil -- 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: Peter Eisentraut on 31 Dec 2009 04:04 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 > JSON > object? How will we be able to set values inside them? 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. -- 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: "Greg Sabino Mullane" on 31 Dec 2009 07:59
-----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 particularly relevant. I don't use JSON, but I do use YAML. Attached, please find a patch that implements hstore_to_yaml(). .....just kidding. :) > I think we are getting the cart way before the horse. +1. Smells like a solution in search of a problem, as they say. - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 200912310759 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAks8oC4ACgkQvJuQZxSWSsgHfQCgznfnazYgVDz9ak5xfQZj6Fsk b6UAoMH/v3Lu0R+wkoN024GcZtxqpEI2 =ELcu -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |