Re: [HACKERS] adding an immutable variant of to_date
От | Sven R. Kunze |
---|---|
Тема | Re: [HACKERS] adding an immutable variant of to_date |
Дата | |
Msg-id | 270863fe-dc6c-ac8a-11d6-e35797937cb1@mail.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] adding an immutable variant of to_date (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: [HACKERS] adding an immutable variant of to_date
Re: [HACKERS] adding an immutable variant of to_date |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: