Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when
 extracting epoch
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: David Steele <david@pgmasters.net>,
 Pavel Stehule <pavel.stehule@gmail.com>,
 Thomas Munro <thomas.munro@gmail.com>,
 Petr Fedorov <petr.fedorov@phystech.edu>, Tom Lane <tgl@sss.pgh.pa.us>
References: 
 <CA+hUKGK+K8NyS57tU841m1tSF6ha3W0udN2dw_Hbc=D_0OPbmA@mail.gmail.com>
 <ee683994-8f7c-aded-be43-543e66e68b94@2ndquadrant.com>
 <a3be61d9-f44b-7fce-3dc8-d700fdfb6f48@2ndquadrant.com>
 <CAFj8pRC8cgoiQMT235cky4Pa40gj=s0m3PftmaJLSt9MAiwj_Q@mail.gmail.com>
 <be30c07c-3f7b-7c86-f1c5-d0858046b26f@2ndquadrant.com>
 <1551357.1599435992@sss.pgh.pa.us>
 <097a4242-0748-98e3-06ab-ded1d366cd76@2ndquadrant.com>
 <1893468.1599658711@sss.pgh.pa.us>
 <38fc499a-ae52-efb6-aad6-82f812d6782d@2ndquadrant.com>
 <20200917055327.GU2873@paquier.xyz> <20200930071543.GL1996@paquier.xyz>
 <2fb99632-9302-6509-78ce-3aaed3fd7f40@2ndquadrant.com>
 <3ff4be02-1e2b-564f-9b53-3dc561da8218@pgmasters.net>
 <3013402.1615829712@sss.pgh.pa.us>
 <8fae8673-0d5b-12d9-7342-daed0d590594@2ndquadrant.com>
 <901bcfb8-36c8-27b2-b148-042392992eeb@2ndquadrant.com>
 <4158031.1616184417@sss.pgh.pa.us>
 <75db3efe-8023-58ef-9ee4-8a6a3101c7ca@2ndquadrant.com>
Message-ID: <7594008a-5f47-ae29-3122-42d13228fd9e@2ndquadrant.com>
Date: Tue, 6 Apr 2021 07:48:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <75db3efe-8023-58ef-9ee4-8a6a3101c7ca@2ndquadrant.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/7594008a-5f47-ae29-3122-42d13228fd9e%402ndquadrant.com>
Precedence: bulk

On 01.04.21 20:49, Peter Eisentraut wrote:
> also done
> 
> I also figured out a way to combine the float8 and numeric 
> implementations so that there is not so much duplication.  Added tests 
> to cover all the edge and overflow cases.
> 
> I think this is solid now.
> 
> The extract(julian from timestamp) is still a bit in the slow mode, but 
> as I previously stated, it's not documented and gives the wrong result, 
> so it's not clear whether it should be fixed and what it should do.  I 
> think I'll register that part as an open item in any case, to see what 
> we should do about that.

committed and done