Re: JSON manipulation functions

From: Mike Rylander <mrylander(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, magnus(at)hagander(dot)net
Subject: Re: JSON manipulation functions
Date: 2010-05-14 17:47:08
Message-ID: AANLkTikdYc_L1QhFh33JTsNqjAtNnsPBUY0pdRjK2JaG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 14, 2010 at 1:15 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
> <joeyadams3(dot)14159(at)gmail(dot)com> wrote:

[snip]

>> == array/object conversion ==
>>
>> The json_object function converts a tuple to a JSON object.  If there
>> are duplicate column names, there will be duplicate keys in the
>> resulting JSON object.
>>
>> json_object([content [AS name] [, ...]]) returns json
>
> Seems good.
>
>> Likewise, the json_array function converts a tuple to a JSON array.
>> Column names are ignored.
>>
>> json_array([content [AS name] [, ...]]) returns json
>
> I think this is pointless and should be omitted.
>

(I'm going to avoid the use of the term "object" here to reduce confusion.)

I disagree with the assertion that it's pointless, and I have a
specific use-case in mind for this function. I have a system that
uses JSON arrays on the wire to encapsulate data, and both ends
understand the positional semantics of the elements. Using JSON
arrays instead of JSON objects reduces the transfer size by 40-80%,
depending on how "full" the rows (or class instances) are and the data
types of the elements, simply by removing the redundant object keys.
This function would be extremely useful to me when creating or
persisting raw class instances of these sorts.

--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: miker(at)esilibrary(dot)com
| web: http://www.esilibrary.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-14 18:18:42 recovery consistent != hot standby
Previous Message Marc G. Fournier 2010-05-14 17:42:30 Re: List traffic