From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb and nested hstore |
Date: | 2014-02-11 09:35:51 |
Message-ID: | 52F9EEF7.3000307@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/11/2014 01:16 AM, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> It works in enough cases atm that it's worthwile trying to keep it
>> working. Sure, it could be better, but it's what we have right now. Atm
>> it's e.g. the only realistic way to copy larger amounts of bytea between
>> servers without copying the entire cluster.
> That's the thing -- it might work today, but what about tomorrow?
> We'd be sending the wrong signals. People start building processes
> around all of this and now we've painted ourselves into a box. Better
> in my mind to simply educate users that this practice is dangerous and
> unsupported, as we used to do. I guess until now. It seems completely
> odd to me that we're attaching a case to the jsonb type, in the wrong
> way -- something that we've never attached to any other type before.
> For example, why didn't we attach a version code to the json type send
> function?
JSON is supposed to be a *standard* way of encoding data in
strings. If the ever changes, it will not be JSON type anymore.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2014-02-11 10:05:50 | Re: Row-security on updatable s.b. views |
Previous Message | Craig Ringer | 2014-02-11 08:36:10 | Re: Row-security on updatable s.b. views |