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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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