Re: JSON[B] arrays are second-class citizens - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: JSON[B] arrays are second-class citizens
Date
Msg-id CAFj8pRDvpRJU4zLyZFO8kGL7bxH0vMod2_qmu_j2Pb1MTMZGuA@mail.gmail.com
Whole thread Raw
In response to Re: JSON[B] arrays are second-class citizens  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers


2016-06-01 17:55 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 5/31/16 7:04 PM, Peter van Hardenberg wrote:
The idea of converting a JSONB array to a PG array is appealing and
would potentially be more general-purpose than adding a new unnest. I'm
not sure how feasible either suggestion is.

The one part I think is missing right now is unnest allows you to 'stitch' or 'zip' multiple arrays together into a single recordset via unnest(array1, array2, ...). Presumably that could be added to the json equivalents.

I will say that I think the current state of affairs is gratuitously
verbose and expects users to memorize a substantial number of long
function names to perform simple tasks.

+100. It's *much* easier to deal with JSON in other languages because they have native support for the concept of a dictionary, so changing an element is as simple as json['foo'][3] = 'new'. Trying to do that in Postgres is horrible partly because of the need to remember some odd operator, but moreso because it's ultimately still an operator. What we need is a form of *addressing*. If you could directly access items in a JSON doc with [] notation then a lot of the current functions could go away, *especially* if the [] notation allowed things like a slice and a list of values (ie: json['foo', 'bar', 'baz'] = '[42,{"my": "nice object"},"with a random string"]'. Or = row(42, ...).

these features I would to see in Postgres too.

Regards

Pavel
 
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Misdesigned command/status APIs for parallel dump/restore
Next
From: Tom Lane
Date:
Subject: Re: Floating point comparison inconsistencies of the geometric types