Re: to_timestamp docs

From: Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: to_timestamp docs
Date: 2019-05-01 22:03:38
Message-ID: CAKNkYnwZS8n+VJ2rVae5EV-NYv8nVL2B1_tcmyDAuTme6afX7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 2, 2019 at 12:49 AM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > It works globally (but only for remaining string if you don't put it
> > at the beginning)
> > and you can set it only once. For example:
> >
> > =# SELECT to_timestamp('JUL JUL JUL','FXMON_MON_MON');
> > ERROR: invalid value " J" for "MON"
> > DETAIL: The given value did not match any of the allowed values for this field.
>
> Actually, FX takes effect on subsequent format patterns. This is not
> documented, but it copycats Oracle behavior. Sure, normally FX should
> be specified as the first item. We could document current behavior or
> restrict specifying FX not as first item. This is also not new in 12,
> so documenting current behavior is better for compatibility.

I went to Oracle's documentation. It seems that the behavior is
slightly different.
Their documentation says:

"A modifier can appear in a format model more than once. In such a case,
each subsequent occurrence toggles the effects of the modifier. Its effects are
enabled for the portion of the model following its first occurrence, and then
disabled for the portion following its second, and then reenabled for
the portion
following its third, and so on."

In PostgreSQL one cannot disable exact mode using second FX. I think we
shouldn't add some restriction for FX. Instead PostgreSQL's documentation
can be fixed. And current explanation in the documentation might be wrong as
Bruce pointed.

--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-01 23:01:23 Re: [HACKERS] Commits 8de72b and 5457a1 (COPY FREEZE)
Previous Message Bruce Momjian 2019-05-01 22:02:40 Re: to_timestamp docs