From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>
cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>
Subject: Re: Fix parsing of identifiers in jsonpath
In-reply-to: <3603843f-b5fc-d8d9-c842-ccde2288b967@postgrespro.ru>
References: <3603843f-b5fc-d8d9-c842-ccde2288b967@postgrespro.ru>
Comments: In-reply-to Nikita Glukhov <n.gluhov@postgrespro.ru>
	message dated "Wed, 18 Sep 2019 18:10:27 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11457.1568842096.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Sep 2019 17:28:16 -0400
Message-ID: <11458.1568842096@sss.pgh.pa.us>
Precedence: bulk

Nikita Glukhov <n.gluhov@postgrespro.ru> writes:
> I don't know if it is possible to check Unicode properties "ID_Start" an=
d
> "ID_Continue" in Postgres, and what ZWNJ/ZWJ is.  Now, identifier's star=
ting
> character set is simply determined by the exclusion of all recognized sp=
ecial
> characters.

TBH, I think you should simply ignore any aspect of any of these standards
that is defined by reference to Unicode.  We are not necessarily dealing
with a Unicode character set, so at best, references to things like ZWNJ
are unreachable no-ops in a lot of environments.

As a relevant example, modern SQL defines whitespace in terms of Unicode[1=
],
a fact that we have ignored from the start and will likely continue to
do so.

You could do a lot worse than to just consider identifiers to be the same
strings as our SQL lexer would do (modulo things like "$" that have
special status in the path language).

			regards, tom lane

[1] cf 4.2.4 "Character repertoires" in SQL:2011