From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Peter van Hardenberg <pvh(at)pvh(dot)ca>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: JSON[B] arrays are second-class citizens |
Date: | 2016-06-01 18:40:19 |
Message-ID: | CAFj8pRDvpRJU4zLyZFO8kGL7bxH0vMod2_qmu_j2Pb1MTMZGuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-06-01 17:55 GMT+02:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-01 18:52:05 | Re: Floating point comparison inconsistencies of the geometric types |
Previous Message | Tom Lane | 2016-06-01 18:29:30 | Re: Misdesigned command/status APIs for parallel dump/restore |