From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
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 20:31:52 |
Message-ID: | 1255593.1621974712@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-05-25 20:33:54 | Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
Previous Message | Stephen Frost | 2021-05-25 20:29:08 | Re: storing an explicit nonce |