Thread: Re: doc: improve PG 12 to_timestamp()/to_date() wording
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
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
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
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
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 +