Re: JSON and unicode surrogate pairs

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

In response to

Browse pgsql-hackers by date

  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