Re: Ltree syntax improvement

From: Dmitry Belyavsky <beldmit(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Ltree syntax improvement
Date: 2019-07-08 19:11:42
Message-ID: CADqLbz+gUmusJYivWCqFt=LgEXsX5OUQBKZXQDDx4b3dtA23MQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Thomas,

Thank you for your proofreading!

Please find the updated patch attached. It also contains the missing
escaping.

On Mon, Jul 8, 2019 at 10:39 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Wed, Apr 17, 2019 at 5:29 AM Dmitry Belyavsky <beldmit(at)gmail(dot)com>
> wrote:
> > I've applied your patch.
> > From my point of view, there is no major difference between case and
> chain if here.
> > Neither case nor ifs allow extracting the common code to separate
> function - just because there seem to be no identical pieces of code.
>
> Hi Dmitry,
>
> The documentation doesn't build[1], due to invalid XML. Since I'm
> here, here is some proof-reading of the English in the documentation:
>
> <para>
> - A <firstterm>label</firstterm> is a sequence of alphanumeric characters
> - and underscores (for example, in C locale the characters
> - <literal>A-Za-z0-9_</literal> are allowed). Labels must be less
> than 256 bytes
> - long.
> + A <firstterm>label</firstterm> is a sequence of characters. Labels
> must be
> + less than 256 symbols long. Label may contain any character
> supported by Postgres
>
> "fewer than 256 characters in length", and
> "<productname>PostgreSQL</productname>"
>
> + except <literal>\0</literal>. If label contains spaces, dots,
> lquery modifiers,
>
> "spaces, dots or lquery modifiers,"
>
> + they may be <firstterm>escaped</firstterm>. Escaping can be done
> either by preceeding
> + backslash (<literal>\\</literal>) symbol, or by wrapping the label
> in whole in double
> + quotes (<literal>"</literal>). Initial and final unescaped
> whitespace is stripped.
>
> "Escaping can be done with either a preceding backslash [...] or by
> wrapping the whole label in double quotes [...]."
>
> </para>
>
> + During converting text into internal representations, wrapping
> double quotes
>
> "During conversion to internal representation, "
>
> + and escaping backslashes are removed. During converting internal
> + representations into text, if the label does not contain any special
>
> "During conversion from internal representation to text, "
>
> + symbols, it is printed as is. Otherwise, it is wrapped in quotes and,
> if
> + there are internal quotes, they are escaped with backslash. The
> list of special
>
> "escaped with backslashes."
>
> + <para>
> + Examples: <literal>42</literal>, <literal>"\\42"</literal>,
> + <literal>\\4\\2</literal>, <literal> 42 </literal> and <literal> "42"
> + </literal> will have the similar internal representation and, being
>
> "will all have the same internal representation and,"
>
> + converted from internal representation, will become
> <literal>42</literal>.
> + Literal <literal>abc def</literal> will turn into <literal>"abc
> + def"</literal>.
> </para>
>
> [1] https://travis-ci.org/postgresql-cfbot/postgresql/builds/555571856
>
> --
> Thomas Munro
> https://enterprisedb.com
>

--
SY, Dmitry Belyavsky

Attachment Content-Type Size
ltree_20190708.diff text/x-patch 77.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-07-08 19:15:24 Re: tableam: abstracting relation sizing code
Previous Message Julien Rouhaud 2019-07-08 19:08:43 Re: Add parallelism and glibc dependent only options to reindexdb