Re: jsonb and nested hstore

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Ü

In response to

Responses

Browse pgsql-hackers by date

  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