From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: JSON and unicode surrogate pairs |
Date: | 2013-06-10 22:40:30 |
Message-ID: | 51B655DE.9050302@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/10/2013 06:07 PM, Robert Haas wrote:
> On Mon, Jun 10, 2013 at 10:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, if we have to break backwards compatibility when we try to do
>> binary storage, we're not going to be happy either. So I think we'd
>> better have a plan in mind for what will happen then.
> Who says we're ever going to do any such thing? This was extensively
> debated when we added the original type, and I thought that it was
> agreed that we might ultimately need both a type that stored JSON as
> text and another that stored it as binary. And we might need an
> XML-binary type as well. But there are also cases where storing the
> data as text is *better*, and I don't see us ever getting rid of that.
>
It was discussed at Pgcon as a result of Oleg and Teodor's talk, and at
the Unconference.
But in any case it's moot here. None of what I'm suggesting has anything
to do with the storage representation of JSON, only with how we process
it in whatever form. And none of it will break backwards compatibility
at all.
So, please, let's concentrate on the problem that's actually at hand.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2013-06-10 22:45:46 | Re: Hard limit on WAL space used (because PANIC sucks) |
Previous Message | Hannu Krosing | 2013-06-10 22:34:01 | Re: JSON and unicode surrogate pairs |