Re: Add ZSON extension to /contrib/

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add ZSON extension to /contrib/
Date: 2021-05-25 21:06:29
Message-ID: 512236b0-674c-a3e8-e350-0d96ae72c1a9@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 5/25/21 4:31 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 5/25/21 4:10 PM, Tom Lane wrote:
>>> Also, even if ZSON was "100% compatible with JSONB" back in 2016,
>>> a whole lot of features have been added since then. Having to
>>> duplicate all that code again for a different data type is not
>>> something I want to see us doing. So that's an independent reason
>>> for wanting to hide this under the existing type not make a new one.
>> I take your point. However, there isn't really any duplication. It's
>> handled by [ creating a pair of casts ]
> If that were an adequate solution then nobody would be unhappy about
> json vs jsonb. I don't think it really is satisfactory:
>
> * does nothing for user confusion (except maybe make it worse)
>
> * not terribly efficient
>
> * doesn't cover all cases, notably indexes.
>
>

Quite so. To some extent it's a toy. But at least one of our customers
has found it useful, and judging by Aleksander's email they aren't
alone. Your ideas downthread are probably a useful pointer of how we
might fruitfully proceed.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-05-25 21:12:05 Re: storing an explicit nonce
Previous Message Bruce Momjian 2021-05-25 21:04:56 Re: storing an explicit nonce