Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jdGKf-0008Bs-8j
	for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2020 16:52:09 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jdGKe-0006oN-66
	for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2020 16:52:08 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <vik@postgresfriends.org>)
	id 1jdGKd-0006oG-Vg
	for pgsql-hackers@lists.postgresql.org; Mon, 25 May 2020 16:52:07 +0000
Received: from relay2-d.mail.gandi.net ([217.70.183.194])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <vik@postgresfriends.org>)
	id 1jdGKb-0002c4-NW
	for pgsql-hackers@postgresql.org; Mon, 25 May 2020 16:52:07 +0000
X-Originating-IP: 93.10.30.82
Received: from [172.16.255.146] (82.30.10.93.rev.sfr.net [93.10.30.82])
	(Authenticated sender: vik@postgresfriends.org)
	by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 4747B40009;
	Mon, 25 May 2020 16:52:01 +0000 (UTC)
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when
 extracting epoch
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 Thomas Munro <thomas.munro@gmail.com>,
 Petr Fedorov <petr.fedorov@phystech.edu>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
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>
From: Vik Fearing <vik@postgresfriends.org>
Message-ID: <428767b1-6a18-cc5a-bb2f-a78bc306fae3@postgresfriends.org>
Date: Mon, 25 May 2020 18:52:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <5752.1590424827@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

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