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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
