Re: [HACKERS] Bug in to_timestamp().

> On 1 February 2018 at 11:24, Arthur Zakirov <a.zakirov@postgrespro.ru> wrote:
>
> I fixed those messages, but in a different manner. I think that an
> unexpected character is unknown and neither space nor separator. And
> better to say that was expected space/separator character.

Sounds good, thanks.

> Attached fixed patch.

For some reason I can't apply it clean to the latest master:

    (Stripping trailing CRs from patch; use --binary to disable.)
    patching file doc/src/sgml/func.sgml
    (Stripping trailing CRs from patch; use --binary to disable.)
    patching file src/backend/utils/adt/formatting.c
    (Stripping trailing CRs from patch; use --binary to disable.)
    patching file src/test/regress/expected/horology.out
    Hunk #1 FAILED at 2769.
    Hunk #2 FAILED at 2789.
    Hunk #3 succeeded at 2810 with fuzz 2.
    Hunk #4 succeeded at 2981 with fuzz 2.
    Hunk #5 succeeded at 3011 with fuzz 2.
    Hunk #6 FAILED at 3029.
    3 out of 6 hunks FAILED -- saving rejects to file
src/test/regress/expected/horology.out.rej
    (Stripping trailing CRs from patch; use --binary to disable.)
    patching file src/test/regress/sql/horology.sql

> On 2 February 2018 at 16:40, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I'm not quite sure whether it's relevant here, but I think some of the
> ctype.h functions have locale-dependent behavior.  By implementing our
> own test we make sure that we don't accidentally inherit any such
> behavior.

Yes, you're right, `isalpha` is actually locale dependent function.

    In some locales, there may be additional characters for which isalpha() is
    true—letters which are neither uppercase nor lowercase.

So, if I understand the patch correctly, with `isalpha` the function
`is_separator_char` will return false for some locale-specific characters, and
without - those characters will be treated as separators. Is it desire
behavior?