From: Nikolay Shaplov <dhyan@nataraj.su>
To: pgsql-hackers@lists.postgresql.org
Cc: Chris Travers <chris.travers@adjust.com>,
 Dmitry Belyavsky <beldmit@gmail.com>
Subject: Re: Ltree syntax improvement
Date: Sun, 31 Mar 2019 22:01:03 +0300
Message-ID: <2022407.P79Vr7n7W3@x200m>
User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; )
In-Reply-To: 
 <CAN-RpxAvzVSxqsqXhksM8YRNyiO8Nrtw+eTdJ9_p3CBXBU3F5w@mail.gmail.com>
References: 
 <CADqLbzLVkBuPX0812o+z=c3i6honszsZZ6VQOSKR3VPbB56P3w@mail.gmail.com>
 <30381329.7fST72pxSh@x200m>
 <CAN-RpxAvzVSxqsqXhksM8YRNyiO8Nrtw+eTdJ9_p3CBXBU3F5w@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

=D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 =D1=87=D0=B5=D1=82=
=D0=B2=D0=B5=D1=80=D0=B3, 7 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2019 =D0=B3. 13:=
09:49 MSK =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Chris Travers=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

>  We maintain an extension (https://github.com/adjust/wltree)
> which has a fixed separator (::) and allows any utf-8 character in the tr=
ee.
>=20
> In our case we currently use our extended tree to store user-defined
> hierarchies of labels, which might contain whitespace, Chinese, Japanese,
> or Korean characters, etc.
>=20
> I would love to be able to deprecate our work on this extension and
> eventually use stock ltree.
I am afraid, that if would not be possible to have ltree with custom=20
separator. Or we need to pass a very long way to reach there.

To have custom separator we will need some place to store it.

We can use GUC variable, and set separator for ltree globally. It might sol=
ve=20
some of the problems. But will get some more. If for example we dump databa=
se,=20
and then restore it on instance where that GUC option is not set, everythin=
g=20
will be brocken.

It is not opclass option (that are discussed  here on the list), because=20
opclass options is no about parsing, but about comparing things that was=20
already parsed.

It is not option of an attribute (if we can have custom attribute option),=
=20
because we can have ltree as a variable, without creating an attribute...

It should be an option of ltree type itself. I have no idea how we can=20
implement this. And who will allow us to commit such strange thing ;-)