| From: | David Steele <david(at)pgmasters(dot)net> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
| Date: | 2021-03-15 12:18:29 |
| Message-ID: | 3ff4be02-1e2b-564f-9b53-3dc561da8218@pgmasters.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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?
Regards,
--
-David
david(at)pgmasters(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2021-03-15 14:19:57 | BUG #16927: Postgres can`t access WAL files |
| Previous Message | Regina Obe | 2021-03-15 00:31:06 | RE: BUG #16920: Can't compile PostGIS with MingW64 against PostgreSQL 14 head |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2021-03-15 12:25:15 | Re: jsonpath syntax extensions |
| Previous Message | gkokolatos | 2021-03-15 12:18:12 | Re: PATCH: Attempt to make dbsize a bit more consistent |