Re: doc: improve PG 12 to_timestamp()/to_date() wording

Hi!

I'd like to add couple of comments from my side.

On Tue, Apr 30, 2019 at 9:36 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I saw this commit;
> commit ad23adc5a169b114f9ff325932cbf2ce1c5e69c1
> |Author: Bruce Momjian <bruce(at)momjian(dot)us>
> |Date: Tue Apr 30 14:06:57 2019 -0400
> |
> | doc: improve PG 12 to_timestamp()/to_date() wording
>
> which cleans up language added at cf984672.
>
> Can I suggest this additional change, which is updated and extracted from my
> larger set of documentation fixes.
>
> Justin
>
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 96fafdd..b420585 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -6400,20 +6400,20 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
> </para>
> <para>
> If <literal>FX</literal> is specified, a separator in the template string
> - matches exactly one character in input string. Notice we don't insist the
> - input string character be the same as the template string separator.
> + matches exactly one character in the input string. But note that the
> + input string character is not required to be the same as the separator from the template string.

Looks good for me.

> For example, <literal>to_timestamp('2000/JUN', 'FXYYYY MON')</literal>
> works, but <literal>to_timestamp('2000/JUN', 'FXYYYY&nbsp;&nbsp;MON')</literal>
> - returns an error because the second template string space is consumed
> - by the letter <literal>J</literal> in the input string.
> + returns an error because the second space in the template string consumes
> + the letter <literal>M</literal> from the input string.
> </para>
> </listitem>

Why <literal>M</literal>? There is no letter "M" is input string.
The issue here is that we already consumed "J" from "JUN" and trying
to match "UN" to "MON". So, I think we should live
<literal>J</literal> here. The rest of this change looks good.

> <listitem>
> <para>
> A <literal>TZH</literal> template pattern can match a signed number.
> - Without the <literal>FX</literal> option, it can lead to ambiguity in
> - interpretation of the minus sign, which can also be interpreted as a separator.
> + Without the <literal>FX</literal> option, minus signs may be ambiguous,
> + and could be interpreted as a separator.
> This ambiguity is resolved as follows: If the number of separators before
> <literal>TZH</literal> in the template string is less than the number of
> separators before the minus sign in the input string, the minus sign

Looks good for me.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company