From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Mike Rylander <mrylander(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: Add JSON support |
Date: | 2010-03-29 00:33:51 |
Message-ID: | 603c8f071003281733t5fb767d0pdd6c84d39f435b1d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander <mrylander(at)gmail(dot)com> wrote:
> In practice, every parser/serializer I've used (including the one I
> helped write) allows (and, often, forces) any non-ASCII character to
> be encoded as \u followed by a string of four hex digits.
Is it correct to say that the only feasible place where non-ASCII
characters can be used is within string constants? If so, it might be
reasonable to disallow characters with the high-bit set unless the
server encoding is one of the flavors of Unicode of which the spec
approves. I'm tempted to think that when the server encoding is
Unicode we really ought to allow Unicode characters natively, because
turning a long string of two-byte wide chars into a long string of
six-byte wide chars sounds pretty evil from a performance point of
view.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-03-29 00:46:11 | Re: Proposal: Add JSON support |
Previous Message | Mike Rylander | 2010-03-29 00:23:06 | Re: Proposal: Add JSON support |