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

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

From
Justin Pryzby
Date:
Hi Bruce

I saw this commit;
commit ad23adc5a169b114f9ff325932cbf2ce1c5e69c1
|Author: Bruce Momjian <bruce@momjian.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.
        For example, <literal>to_timestamp('2000/JUN', 'FXYYYY MON')</literal>
        works, but <literal>to_timestamp('2000/JUN', 'FXYYYY  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>
 
      <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

Attachment

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

From
Alexander Korotkov
Date:
Hi!

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

On Tue, Apr 30, 2019 at 9:36 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> I saw this commit;
> commit ad23adc5a169b114f9ff325932cbf2ce1c5e69c1
> |Author: Bruce Momjian <bruce@momjian.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  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



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

From
Justin Pryzby
Date:
On Tue, Apr 30, 2019 at 09:48:14PM +0300, Alexander Korotkov wrote:
> I'd like to add couple of comments from my side.

> > -       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.
> 
> 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.

Seems like I confused myself while resolving rebase conflict.

Thanks for checking.

Justin



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

From
Justin Pryzby
Date:
On Tue, Apr 30, 2019 at 07:14:04PM -0500, Justin Pryzby wrote:
> On Tue, Apr 30, 2019 at 09:48:14PM +0300, Alexander Korotkov wrote:
> > I'd like to add couple of comments from my side.
> 
> > > -       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.
> > 
> > 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.
> 
> Seems like I confused myself while resolving rebase conflict.
> 
> Thanks for checking.

Find attached updated patch, which seems to still be needed.

This was subsumed and now extracted from a larger patch, from which Michael at
one point applied a few hunks.
I have some minor updates based on review from Andres, but there didn't seem to
be much interest so I haven't pursued it.
https://www.postgresql.org/message-id/20190520182001.GA25675%40telsasoft.com

Justin

Attachment

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

From
Bruce Momjian
Date:
On Sat, Jul  6, 2019 at 03:24:25PM -0500, Justin Pryzby wrote:
> On Tue, Apr 30, 2019 at 07:14:04PM -0500, Justin Pryzby wrote:
> > On Tue, Apr 30, 2019 at 09:48:14PM +0300, Alexander Korotkov wrote:
> > > I'd like to add couple of comments from my side.
> > 
> > > > -       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.
> > > 
> > > 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.
> > 
> > Seems like I confused myself while resolving rebase conflict.
> > 
> > Thanks for checking.
> 
> Find attached updated patch, which seems to still be needed.
> 
> This was subsumed and now extracted from a larger patch, from which Michael at
> one point applied a few hunks.
> I have some minor updates based on review from Andres, but there didn't seem to
> be much interest so I haven't pursued it.
> https://www.postgresql.org/message-id/20190520182001.GA25675%40telsasoft.com

Patch applied back through PG 12.  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +