pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Steele <david@pgmasters.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Petr Fedorov <petr.fedorov@phystech.edu>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Date: Mon, 15 Mar 2021 13:35:12 -0400
Message-ID: <3013402.1615829712@sss.pgh.pa.us> (raw)
In-Reply-To: <3ff4be02-1e2b-564f-9b53-3dc561da8218@pgmasters.net>
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>

David Steele <david@pgmasters.net> writes:
> On 12/15/20 9:03 AM, Peter Eisentraut wrote:
>> Here is a new patch for this.  This now follows the implementation that 
>> Tom has suggested:  Leave date_part() alone, add a new set of extract() 
>> functions, and map the SQL EXTRACT construct to those.  I have basically 
>> just copied over the implementations from my previous patch and placed 
>> them next to the existing date_part() implementations.  So all the 
>> behavior is still the same as in the previous patches.
>> 
>> One thing I still need to look into is how to not lose all the test 
>> coverage for date_part().  But that should be fairly mechanical, so I'm 
>> leaving it off in this version.

> Tom, what do you think of the updated patch?

Oh, I didn't think I was on the hook to review this ;-)

Anyway, taking a quick look at the v4 patch, the only complaint
I have is that it seems a bit bulky and brute-force to duplicate
so much code.  Is it feasible to share most of the implementation
between old and new functions, returning (say) an int64 that can
then be converted to either numeric or float8 by a wrapper?  That
would also reduce the pressure to duplicate all the test cases.

(I don't intend this complaint as a deal-breaker; Peter may well
have considered this alternative already and rejected it for good
reasons.)

			regards, tom lane





view thread (47+ messages)  latest in thread

Message-ID: <3013402.1615829712@sss.pgh.pa.us>
Permalink:  ../3013402.1615829712@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3013402.1615829712@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, david@pgmasters.net, peter.eisentraut@2ndquadrant.com, pavel.stehule@gmail.com, thomas.munro@gmail.com, petr.fedorov@phystech.edu, pgsql-hackers@postgresql.org
  Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
  In-Reply-To: <3013402.1615829712@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox