Re: Extract epoch from Interval weird behavior - Mailing list pgsql-hackers

From Joseph Koshakow
Subject Re: Extract epoch from Interval weird behavior
Date
Msg-id CAAvxfHc_KtR56uK=nKJzvBst91mCk0O3RMB-g22AXC4Qvef_Mw@mail.gmail.com
Whole thread Raw
In response to Re: Extract epoch from Interval weird behavior  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Extract epoch from Interval weird behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Frontend error logging style
Next
From: Tom Lane
Date:
Subject: Re: convert libpq uri-regress tests to tap test