From: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Extract epoch from Interval weird behavior |
Date: | 2022-02-24 15:17:27 |
Message-ID: | CAAvxfHc_KtR56uK=nKJzvBst91mCk0O3RMB-g22AXC4Qvef_Mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 24, 2022 at 4:47 AM Aleksander Alekseev
<aleksander(at)timescale(dot)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 behavior for 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 instead is 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(at)phystech(dot)edu
- Joe Koshakow
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-24 15:17:28 | Re: convert libpq uri-regress tests to tap test |
Previous Message | Tom Lane | 2022-02-24 15:10:41 | Re: Frontend error logging style |