Date: Sat, 6 Jul 2019 15:24:25 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: doc: improve PG 12 to_timestamp()/to_date() wording
Message-ID: <20190706202425.GA16933@telsasoft.com>
References: <20190430183636.GA8175@telsasoft.com>
 <CAPpHfduhdg+bXjzg9nbpk-ZrCsNP3QFvRv33Vmi+k3_TjwftXA@mail.gmail.com>
 <20190501001403.GN3925@telsasoft.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
In-Reply-To: <20190501001403.GN3925@telsasoft.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--IJpNTDwzlM2Ie8A6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="v3-0008-Clean-up-language-in-cf984672-Improve-behavior-of.patch"

From 2ca5c2f2f8ad8bb8a681aea7ca78131f1f99d756 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 30 Mar 2019 03:42:35 -0500
Subject: [PATCH v3 08/12] Clean up language in cf984672: Improve behavior of
 to_timestamp()/to_date() functions

---
 doc/src/sgml/func.sgml | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d425731..c5f1828 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -6426,20 +6426,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&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>J</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
-- 
2.7.4


--IJpNTDwzlM2Ie8A6--