Re: Bug in to_timestamp().

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Bug in to_timestamp().
Дата
Msg-id 576DB79F.1000001@commandprompt.com
обсуждение исходный текст
Ответ на Re: Bug in to_timestamp().  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bug in to_timestamp().  (Steve Crawford <scrawford@pinpointresearch.com>)
Список pgsql-hackers
On 06/24/2016 02:16 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
>> <scrawford@pinpointresearch.com> wrote:
>>> To me, 2016-02-30 is an invalid date that should generate an error.
>
>> I don't particularly disagree with that, but on the other hand, as
>> mentioned earlier, to_timestamp() is here for Oracle compatibility,
>> and if it doesn't do what Oracle's function does, then (1) it's not
>> useful for people migrating from Oracle and (2) we're making up the
>> behavior out of whole cloth.  I think things that we invent ourselves
>> should reject stuff like this, but in a compatibility function we
>> might want to, say, have compatibility.
>
> Agreed, mostly, but ... how far are we prepared to go on that?

We don't at all. Our goal has never been Oracle compatibility. Yes, we 
have "made allowances" but we aren't in a position that requires that 
anymore.

Let's just do it right.

Sincerely,

JD

/me speaking as someone who handles many, many migrations, none of which 
have ever said, "do we have Oracle compatibility available".

-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrey Zhidenkov
Дата:
Сообщение: Memory leak in Pl/Python
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: MultiXactId error after upgrade to 9.3.4