PATCH: Add hstore_to_json()
in [PgSql]
|
From: Robert Haas on 31 Dec 2009 19:24 On Thu, Dec 31, 2009 at 5:37 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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. OK, that's why I ask these questions. :-) How much would be "siz(e)able"? ....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: Dimitri Fontaine on 1 Jan 2010 04:41 Andrew Dunstan <andrew(a)dunslane.net> writes: >> 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 It's there in debian too, unstable and testing, and should be there on the next stable (squeeze): http://packages.debian.org/source/sid/yajl Regards, -- dim -- 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 1 Jan 2010 14:03 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 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. Whose requirement is it? I'm not ignoring it, but so far no one has actually said that it is a requirement and why. -- 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 1 Jan 2010 17:19 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 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 modify sessions with certain characteristics. I'm sure I wouldn't be the only possible usewr who would want something substantially more of such a type than just being able to validate it. We have XPath for XML. and a substantial accessor API for hstore, so why would we want anything less for JSON? In general we have adopted an approach that allows for a very rich type system, with a substantial set of manipulator functions for almost all types. That's one of the things I find attractive about Postgres, so I think we should stick to it in this instance. 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 1 Jan 2010 17:50
Andrew Dunstan <andrew(a)dunslane.net> 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 way to support JSON operations that aren't implemented by the library we pick (which I think is Peter's underlying point) but at the same time the set of supported operations ought to be a factor in which library we pick (which I think is Andrew's point). So it would be a good idea to try to make a list of desirable operations before we go looking at individual libraries. Whether any particular missing features are showstoppers for the use of a given library is something that we can't reasonably determine if we don't have a pre-existing notion of what features we want. Note that it's perfectly reasonable to change our list of desired features based on what we find out about what's actually available --- but we need something to start out with. 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 |