Re: jsonb, unicode escapes and escaped backslashes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)heroku(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb, unicode escapes and escaped backslashes
Date: 2015-01-30 06:20:36
Message-ID: 2127.1422598836@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Attached is a draft patch for this. It basically reverts commit
0ad1a816320a2b539a51628e2a0b1e83ff096b1d, adds a ban of \u0000 if
that would need to be converted to text (so it still works in the
plain json type, so long as you don't do much processing), and adds
some regression tests.

I made the \u0000 error be errcode(ERRCODE_INVALID_TEXT_REPRESENTATION)
and errmsg("invalid input syntax for type json"), by analogy to what's
thrown for non-ASCII Unicode escapes in non-UTF8 encoding. I'm not
terribly happy with that, though. ISTM that for both cases, this is
not "invalid syntax" at all, but an implementation restriction that
forces us to reject perfectly valid syntax. So I think we ought to
use a different ERRCODE and text message, though I'm not entirely
sure what it should be instead. ERRCODE_FEATURE_NOT_SUPPORTED is
one possibility.

regards, tom lane

Attachment Content-Type Size
fix-json-unicode-escape-mess-1.patch text/x-diff 25.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-01-30 06:48:25 Re: PATCH: Reducing lock strength of trigger and foreign key DDL
Previous Message Michael Paquier 2015-01-30 06:10:46 Re: Safe memory allocation functions