From: Vik Fearing <vik@postgresfriends.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.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, 25 May 2020 18:52:01 +0200
Message-ID: <428767b1-6a18-cc5a-bb2f-a78bc306fae3@postgresfriends.org> (raw)
In-Reply-To: <5752.1590424827@sss.pgh.pa.us>
References: <42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu>
<CA+hUKGKgHUbFNKRhvodn4mVU-oqje+HA7jTg_XrWRo4UGhFoqg@mail.gmail.com>
<18389.1575241151@sss.pgh.pa.us>
<1c2262e2-6812-7baa-cbdd-63039db12952@phystech.edu>
<CA+hUKGK+K8NyS57tU841m1tSF6ha3W0udN2dw_Hbc=D_0OPbmA@mail.gmail.com>
<ee683994-8f7c-aded-be43-543e66e68b94@2ndquadrant.com>
<9a680979-ad76-4c3b-1bc0-403152cf49dc@postgresfriends.org>
<5752.1590424827@sss.pgh.pa.us>
On 5/25/20 6:40 PM, Tom Lane wrote:
> Vik Fearing <vik@postgresfriends.org> writes:
>> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>>> I looked into this (changing the return types of date_part()/extract()
>>> from float8 to numeric).
>
>> I think what would be better is to have a specific date_part function
>> for each part and have extract translate to the appropriate one.
>
> Doesn't really work for upwards compatibility with existing views,
> which will have calls to date_part(text, ...) embedded in them.
>
> Actually, now that I think about it, changing the result type of
> date_part() is likely to be problematic anyway for such cases.
> It's not going to be good if pg_upgrade's dump/restore of a view
> results in a new output column type; especially if it's a
> materialized view.
>
> So maybe what we'd have to do is leave date_part() alone for
> legacy compatibility, and invent new functions that the extract()
> syntax would now be translated to.
I'm sorry, I wasn't clear. I was suggesting adding new functions while
also keeping the current generic function. So exactly what you say in
that last paragraph.
Although <extract expression> has a fixed list of constant parts,
date_part() allows the part to be variable. So we need to keep it
anyway for cases like this contrived example:
SELECT date_part(p, now())
FROM UNNEST(ARRAY['epoch', 'year', 'second']) AS u (p)
> While at it, maybe we could
> fix things so that the syntax reverse-lists the same way instead
> of injecting Postgres-isms...
I'm not sure what this means.
--
Vik Fearing
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: vik@postgresfriends.org, tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.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: <428767b1-6a18-cc5a-bb2f-a78bc306fae3@postgresfriends.org>
* 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