Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Date
Msg-id 6816.1590426450@sss.pgh.pa.us
Whole thread Raw
In response to Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch  (Vik Fearing <vik@postgresfriends.org>)
Responses Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
List pgsql-hackers
Vik Fearing <vik@postgresfriends.org> writes:
> On 5/25/20 6:40 PM, Tom Lane wrote:
>> 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.

This:

regression=# create view myview as select extract(year from current_timestamp) as y;
CREATE VIEW
regression=# \d+ myview
...
View definition:
 SELECT date_part('year'::text, CURRENT_TIMESTAMP) AS y;

What had been a 100% spec-compliant view definition is now quite
Postgres-specific.  I fixed some similar problems in 0bb51aa96 (before
that, the CURRENT_TIMESTAMP part would've reverse-listed differently
too); but I didn't tackle EXTRACT(), SUBSTRING(), and other cases.

I'm not claiming that we really need to fix all of those.  But if we are
going to pick nits about which data type EXTRACT() returns then I think
it's legit to worry about its reverse-list representation at the same
time ... especially if we must touch the grammar's translation anyway.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch
Next
From: Tom Lane
Date:
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch