Re: JSON manipulation functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, magnus(at)hagander(dot)net
Subject: Re: JSON manipulation functions
Date: 2010-05-25 16:49:38
Message-ID: AANLkTin2OhgkZXztJGrxJYw5oFjoFd4A_UcgBDto-UNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 25, 2010 at 10:52 AM, Joseph Adams
<joeyadams3(dot)14159(at)gmail(dot)com> wrote:
>> Well, I think it's fine to use the wiki for brainstorming, but before
>> you change the design you probably need to talk about it here.  You
>> can't rely on everyone on -hackers to follow changes on a wiki page
>> somewhere.  It looks like the API has been overhauled pretty heavily
>> since the last version we talked about here, and I'm not sure I
>> understand it.
>
> I'll try to explain it in one big nutshell:
>
> Instead of, for instance, json_to_number('5') and number_to_json(5), I
> propose changing it to from_json(5)::INT and to_json('5').  Note how
> from_json simply returns TEXT containing the underlying value for the
> user to cast.  I plan to make calling to_json/from_json with arrays or
> objects (e.g. to_json(ARRAY[1,2,3]) and from_json('[1,2,3]') ) throw
> an error for now, as implementing all the specifics of this could be
> quite distracting.

I don't see how that's an improvement over the previous design. It
seems like it adds a lot of extra casting and removes useful list
operations without any corresponding advantage.

> If I'm not mistaken, json_object([content [AS name] [, ...]] | *)
> RETURNS json can't be implemented without augmenting the grammar (as
> was done with xmlforest), so I considered making it take a RECORD
> parameter like the hstore(RECORD) function does, as was suggested on
> IRC.  However, this may be inadequate for selecting some columns but
> not others.  Using examples from hstore:
>
> SELECT hstore(foo) FROM foo;  => '"e"=>"2.71828", "pi"=>"3.14159"'
> -- this works, but what if we only want one field?
>
> SELECT hstore(pi) FROM foo;
> -- function type error
>
> SELECT hstore(row(pi)) FROM foo;  => '"f1"=>"3.14159"'
> -- field name is lost
>
> SELECT hstore(bar) FROM (select pi FROM foo) AS bar;  => '"f1"=>"3.14159"'
> -- ugly, and field name is *still* lost

Yeah. I'm not sure what to do about this problem.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-05-25 16:52:49 Re: Synchronization levels in SR
Previous Message MMK 2010-05-25 16:49:06 Confused about the buffer pool size