Skip site navigation (1) Skip section navigation (2)

Re: PATCH: Add hstore_to_json()

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Add hstore_to_json()
Date: 2009-12-30 19:26:32
Message-ID: 4B3BA968.4070602@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Wed, Dec 30, 2009 at 1:23 PM, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-30 19:30:37
Subject: Re: PATCH: Add hstore_to_json()
Previous:From: Robert HaasDate: 2009-12-30 19:25:02
Subject: Re: Hot Standy introduced problem with query cancel behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group