On Wed, Dec 30, 2009 at 2:26 PM, Andrew Dunstan <and...@dunslane.net> wrote: > Robert Haas wrote: >> On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan <and...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
