Re: Extract epoch from Interval weird behavior
От | Joseph Koshakow |
---|---|
Тема | Re: Extract epoch from Interval weird behavior |
Дата | |
Msg-id | CAAvxfHc_KtR56uK=nKJzvBst91mCk0O3RMB-g22AXC4Qvef_Mw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extract epoch from Interval weird behavior (Aleksander Alekseev <aleksander@timescale.com>) |
Ответы |
Re: Extract epoch from Interval weird behavior
|
Список | pgsql-hackers |
On Thu, Feb 24, 2022 at 4:47 AM Aleksander Alekseev <aleksander@timescale.com> wrote: > Extracting an epoch from an interval is quite a strange case since intervals are not connected to any specific dates. I agree, I think it's a weird use case and that it's probably not worth fixing. Though it was fun for me to try. > > All in all, I don't think that the benefit of the proposed change outweighs the fact that it will break the previous behaviorfor the users who may rely on it. I suggest keeping it simple, i.e. the way it is now. What I think we could do insteadis explicitly document this behavior in [1]. > > [1]: https://www.postgresql.org/docs/current/functions-datetime.html I do want to briefly mention, if I'm understanding the history of EXTRACT correctly, that the previous behavior actually was to multiply by 365.25, not 365. However The commit that changed the return type from numeric [1] changed that behavior. Looking through the discussions [2], I don't see any mention of it, which makes me think it was a mistake. However there is a lot of discussion around numeric performance and being able to optimize numeric division because every divisor was a power of 10. Fixing this issue would break that assumption and cause some performance degradations which probably isn't worth it. [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a2da77cdb4661826482ebf2ddba1f953bc74afe4 [2]: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu - Joe Koshakow
В списке pgsql-hackers по дате отправления: