On 1/28/15 11:36 AM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
It's not clear to me how we should represent a unicode null. i.e. given
a json of '["foo\u0000bar"]', I get that we'd store the element as
'foo\x00bar', but what is the result of
(jsonb '["foo\u0000bar"')->>0
It's defined to be text so we can't just shove a binary null in the
middle of it. Do we throw an error?
Yes, that is what I was proposing upthread. Obviously, this needs some
thought to ensure that there's *something* useful you can do with a field
containing a nul, but we'd have little choice but to throw an error if
the user asks us to convert such a field to unescaped text.
I'd be a bit inclined to reject nuls in object field names even if we
allow them in field values, since just about everything you can usefully
do with a field name involves regarding it as text.
Another interesting implementation problem is what does indexing do with
such values --- ISTR there's an implicit conversion to C strings in there
too, at least in GIN indexes.
Anyway, there is a significant amount of work involved here, and there's
no way we're getting it done for 9.4.1, or probably 9.4.anything. I think
our only realistic choice right now is to throw error for \u0000 so that
we can preserve our options for doing something useful with it later.
My $0.01:
While I sympathize with Noah's sentiments, the only thing that makes sense to
me is that a JSON text field is treated the same way as we treat text. Right
now, that means NUL is not allowed, period.
If no one has bitched about this with text, is it really that big a problem
with JSON?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
