Re: to_timestamp docs

On Wed, May 1, 2019 at 11:20:05PM +0300, Arthur Zakirov wrote:
> Hello,
>
> On Wed, May 1, 2019 at 6:05 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Thanks. I think I see the sentence you are thinking of:
> >
> > <function>to_timestamp</function> and <function>to_date</function>
> > skip multiple blank spaces at the beginning of the input string
> > and around date and time values unless the <literal>FX</literal>
> > option is used.
> >
> > However, first, it is unclear what 'skip' means here, i.e., does it mean
> > multiple blank spaces become a single space, or they are ignored.
>
> I worked at to_timestamp some time ago. In this case multiple bank spaces at
> the beginning should be ignored.

OK.

> > Second, I see inconsistent behaviour around the use of FX for various
> > patterns, e.g.:
> >
> > SELECT to_timestamp('5 1976','FXDD_FXYYYY');
> > to_timestamp
> > ------------------------
> > 1976-01-05 00:00:00-05
>
> Hm, I think strspace_len() is partly to blame here, which is called by
> from_char_parse_int_len():
>
> /*
> * Skip any whitespace before parsing the integer.
> */
> *src += strspace_len(*src);
>
> But even if you remove this line of code then strtol() will eat
> survived whitespaces:
>
> result = strtol(init, src, 10);
>
> Not sure if we need some additional checks here if FX is set.

Yes, I suspected it was part of the input function, but it seems it is
done in two places. It seems we need the opposite of strspace_len() in
that place to throw an error if we are in FX mode.

> The problem here is that you need to specify FX only once and at beginning of
> the format string. It is stated in the documentation:
>
> "FX must be specified as the first item in the template."

Uh, FX certainly changes behavior if it isn't the first thing in the
format string.

> It works globally (but only for remaining string if you don't put it
> at the beginning)

Uh, then the documentation is wrong?

--
Bruce Momjian <bruce(at)momjian(dot)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 +