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
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 |