On 07.03.2017 03:21, Andreas Karlsson wrote:
> 1) I do not think we currently allow setting the locale like this
> anywhere, so this will introduce a new concept to PostgreSQL. And you
> will probably need to add support for caching per locale.
Good to know. Could you explain what you mean by "caching per locale"?
> 2) As far as I can tell from reading the code to_date currently
> ignores the M suffix which indicates that you want localized month/day
> names, so i guess that to_date is currently immutable. Maybe it is
> stable due to the idea that we may want to support the M suffix in the
> future.
I think that's the case.
> 3) I do not like the to_date function. It is much too forgiving with
> invalid input. For example 2017-02-30 because 2017-03-02.
That's indeed a funny parsing result. Why does to_date perform this kind
of error-correction?
> Also just ignoring the M suffix in the format string seems pretty bad.
>
> Personally I would rather see a new date parsing function which is
> easier to work with or somehow fix to_date without pissing too many
> users off, but I have no idea if this is a view shared with the rest
> of the community.
Neither do I.
Many business applications have to deal with date(times). I came from
the practical issue of indexing json objects.
Regards,
Sven
