Re: Bug in to_timestamp().
От | Robert Haas |
---|---|
Тема | Re: Bug in to_timestamp(). |
Дата | |
Msg-id | CA+Tgmoa+0VNHiDOCkQVwoxp6AX02PZTdrGSjepL5bWCUB=StyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in to_timestamp(). ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
On Thu, Jun 23, 2016 at 12:37 PM, David G. Johnston <david.g.johnston@gmail.com> wrote > To be honest I don't see how this is relevant to quoted content. And you've > already made this point quite clearly - repeating it isn't constructive. > This behavior has existed for a long time and I don't see that changing it > is a worthwhile endeavor. I believe a new function is required that has > saner behavior. Otherwise given good input and a well-formed parse string > the function does exactly what it is designed to do. Avoid giving it > garbage and you will be fine. Maybe wrap the call to the in a function that > also checks for the expected layout and RAISE EXCEPTION if it doesn't match. Well, I think other people are allowed to disagree about whether changing it is a worthwhile endeavor. I think there's an excellent argument that the current behavior is stupid and broken and probably nobody is intentionally relying on it. Obviously, if somebody is relying on the existing behavior and we change it and it breaks things, then that's bad, and a good argument for worrying about backward-compatibility - e.g. by adding a new function. But who would actually like the behavior that an extra space in the format string causes non-whitespace characters to get skipped? Next you'll be arguing that we can't fix a server crash that's triggered by a certain query because somebody might be relying on that query to restart the server... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: